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Preface 


Manual Objectives 


The DECnet/E Network Installation Guide defines procedures for gener- 
ating, installing and testing a node so that the following criteria are met: 


e The permanent parameter file is configured such that it truly reflects the 
node’s status in the network environment. 


e The communications hardware to be used by the DECnet node is 
functional. 


e All supported adjacent nodes are reachable. 
Intended Audience 


This manual is intended for users who are trained in the operation of 
DECnet/E V2.0. The user should also be trained in the operation of every 
adjacent node within the network in which the node is to be installed. 


Prerequisite Reading 


The user of this manual should be thoroughly familiar with the following 
related documents: 


Introduction to DECnet, Order No. AA-J055B-TK 
RSTSIE System Generation Manual, Order No. AA-2669E-TC 
Update: Order No. AD-2669E-T1 
DECnet/E System Manager’s Guide, Order No. AA-H505B-TC 
DECnet/E Guide to User Utilities, Order No. AA-H504B-TC 
DECnet/E Release Notes, Order No. AA-M269A-TC 
Structure of Manual 


Chapter 1 outlines the procedure for building DECnet/E during the RSTS/E 
system generation and Chapter 2 describes the procedures for configuring 
the node. Local node verification procedures are discussed in Chapter 3 and 
adjacent node verification procedures are discussed in Chapter 4. 


Chapter 1 
Network Specification during SYSGEN 


A DECnet/E system is generated as part of the standard RSTS/E system 
generation procedure. This chapter describes the relevant steps in the 
RSTS/E procedure. These steps are as follows: 


1. Answer the appropriate configuration questions (see Section 1.2). 


2. Mount the DECnet/E distribution medium, as requested by the batch 
stream during the execution of SYSBAT. 


3. Run the BUILD program to build the DECnet/E library programs (see 


Cc Section 1.3). 


After you answer the configuration questions, the SYSBAT batch stream 
transfers the NSP modules from the DECnet/E distribution medium to the 
system disk, where they are linked and installed in RSTS/E. 


To generate the DECnet/E library, run the RSTS/E BUILD program, speci- 
fying the DECnet/E distribution medium and the control file DECNET.CTL 
as input. Driven by this control file, BUILD compiles the DECnet/E library 
programs from the distribution medium and installs them on the system 

Q disk. It also builds the DECnet/E libraries and file transfer software and 
then transfers the model control files to the system disk. 


After the entire library is built and the system generation procedure is com- 
plete, you can tailor the control files to your installation, as discussed in Sec- 
tion 2.4. 


C 1.1. DECnet/E Distribution Kit 


DIGITAL supplies the DECnet/E kit on a separate medium from that con- 
taining the RSTS/E distribution kit. The DECnet/E medium can be mag- 
netic tape or disk cartridge. The distribution medium includes the following 
pertinent files, located in account [1,2]: 


@ Monitor-level software: 


NSP.OBJ 
NSPSUB.OBJ 
TRN.OBJ 
NET.OBJ 
SES.OBJ 
XDDINT.OBJ 
XDDVR.OBJ 


© 
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@ DECnet/E file access software: 
DAP.OLB (and associated NFT and FAL build files) 


@ DECnet/E library programs: 


NCUCVT.BAS 

NETOFF.BAS 

TLK.BAS 

LSN.BAS 

NET.OLB (and associated build files) 
NPK.OLB (and associated build files) 
NCP.OLB (and associated build files) 
NML.OLB (and associated build files) 
NETACT.BAS 

NCROOT.BAS (root for NETCPY) 
NETFNC.BAS (BASIC-—PLUS network function library) 
MIRROR.MAC 


© Control files for building the DECnet/E library: 


DECNET.CTL 
DAPBLD.CTL 


@ Model control and command files for node generation, verification and 
startup 


NCPDEF.CTL (permanent parameter file configuration) 
NTESTE.CTL (local node software verification) 
NTESTH.CTL (local node hardware verification) 
NTESTA.CTL (adjacent Phase III node verification) 
NTEST2.CTL (adjacent Phase II node verification) 
DTSDTR.CTL (adjacent Phase II node verification) 
DECNET.CMD (local node startup) 


The control files in the distribution kit are intended to be run under 
BATCH. (See the RSTS/E System User’s Guide for instructions on running 
the batch processor.) Since a batch control file runs detached, any output 
resulting from execution of the file will be directed to the batch logging file 
rather than to your terminal. At the completion of the BATCH run, you 
should look in the batch logging file for NCP status and counter informa- 
tion, as well as any program-generated error messages. DECnet event log- 
ging messages, however, are output to the designated logging terminal. 


If you are running a RSTS/E configuration that does not have the batch 
processor installed, you must manually type in each of the commands, using 
the control file from the distribution kit as a model. In this case, output will 
be directed to your terminal. 


When analyzing a batch logging file, you should handle any errors and 
unexpected results sequentially. That is, the first error occurring in a veri- 
fication procedure should be corrected and the control file should be rerun 
from the beginning. If many errors result, it may be easier to type in each 
command, using the control file as a model, and correct each problem as it 
occurs. 
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1.2 Configuration Questions 


Only nine RSTS/E configuration questions pertain to DECnet/E system gen- 
eration. These questions are shown below in long form with the default 
answer displays where appropriate. 


The first two questions simply ask whether you want DECnet/E support 
and, if so, what medium your distribution kit is on. 


DECnet/E is a set of modules that implement the network services 
Protocol and user interfaces reauired for DECnet communication, 
The DECnet/E software is sold and distributed as a serarate 
Package. It is not included in the standard RSTS/E Kits Do vou 
have a DECnet/E Kit and wish to include DECnet support in this 
system (YES or NO)? 


DECnet network support ? #Y # 


The DECnet/E package is distributed on magtapes RKOS (DK)» RLOI 
and RLOZ (DL)»+ and RKOG and RKO7Z (DM) cartridge disksi or may 
already have been transferred to the system disk (SY). For mag- 
tape, a distinction must be made between the TU1IO, TE10» and 
TSO3 drives» that use the device name "MT"$ the TUIG» TE1G,s 
TU45,», and TU77 drives» that use the device name "MM"$ and the 
TS11 drivers that uses the device name "MS". Enter the type of 
distribution medium for this DECnet/E generation (MT» MMy+ MS» 
DK» DL» DM» or SY), 


DECnet/E distribution medium ? #MM# 


The next three questions relate to patching the DECnet/E support within 
the RSTS/E operating system. These questions should be answered appro- 
priately if an update to the RSTS/E operating system requires patching the 
DECnet/E software support. In the example below, “Y” was typed so that the 
other questions would appear. Default answers are shown for the remaining 
two questions. 


The system generation Process can automatically Patch the gener- 
ated DECnet/E support. You must have a DECnet/E patch file on 
any RSTS/E file structured medium. Would you like to automati- 
cally patch the DECnet/E support (YES or NO)? 


DECnet/E patching ? HP DH YES 

The DECnet/E patch file can exist on the current system disk 
(SY¥Y)$ another disk (DF+ DK» DL» DM+ DP+ DR» or DB) TUIO» TE10,» 
or TSO3 magtape (MT)$ TUIG,» TE1G» TU45+ or TU77 magtarpe (MM)3 or 
TS11 magtarpe (MS). Enter the name of the patch file medium that 
has your DECnet/E patch file. 


Patch file medium ? Identical to monitor# 


Enter the file name of the DECnet/E patch file. An account num- 
ber (e.d-» £10+23]) or $ (for [1+2]) can be entered along with 
the file name, 


Patch file name 7? #$DECNTC.CMD# 
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The last four questions pertain to the configuration of your system’s commu- 
nications hardware. When answering these questions, consider not only 
your current needs and configuration but also your needs in the near future. 
Specifying numbers larger than you currently have has no major effect 
other than a slightly larger operating system but could save you the effort of 
doing another SYSGEN at a later date. Thus, you should answer the fourth 
question with the number of devices you have, or intend to have in the near 
future, even if you do not expect to turn them all on at once. 


Note that SYSGEN checks the number of DMC11s/DMR11s and DMP11s/ 
DMV11s currently attached to the system for the default answers for the 
first two questions. Note also that the third question, concerning controller 
type, was answered with a “DMP” response. If the question had been 
answered with a “DMV” response, the answer to the fourth question would 
have defaulted to the value 12 rather than 32. 


The DMC11 and DMR1i1 network links are synchronous communication 
line interfaces that implement the DDCMP line protocol in hard- 
ware, RSTS/E supports uP to a maximum of 16 DMCi1l’s or DMR11%5 
Per systems How many DMC1i1’s or DMRii’s are attached to this 
system (0 to 16)? 


DMC11’s/DMR11’s ? #064 


The DMViil and DMPiil network links are synchronous communication 
line interfaces that implement the DDCMP line protocol in hard- 
ware. In the multidrop mode» the DMVY11 can support up to 1? 
tributaries» and the DMPii can suprort up to 32 tributaries, 
RSTS/E supports up to a maximum of 16 DMV1i1’s or DMPii’s per 
systems How many DMVi1l’s or DMPiil’s are attached to this system 
(O to 16)? 


DMVil’s/DMP11’s ? OOH 


hd 


The DMP11 is the Multi-drop DDCMP interface for use on the PDPIi1i 
Unibus$ the DMV11 is its O-bus (PDP-11/23) equivalent. For auto- 
configuration Purposes» you must specify whether you are using 
the Q-bus DMV11 controller or the Unibus DMPii controller. ‘In 
the multidrorp mode» the Q-bus DMVi1 can support up to 12 tribu- 
taries» and the Unibus DMP11 can support up to 32 tributaries, 
Which controller type (DMY or DMP) are vou using? 


Controller type (DMV11/DMP11) ?#DMP# 


If this DMP11 will be operated in "multipoint control" mode» 
sPecify the maximum number of tributaries that will be "on" at 
any one times now or in the foreseeable future. The maximum num- 
ber of simultaneously active tributaries is 16. More tributaries 
than specified can be attached to the lines but only the number 
specified can be simultaneously active, If the DMP11 will be 
operated only in "multipoint slave" or in “point to point" mode» 
sPecify 1. 


DMP11 unit OO tributaries ? #328 


DMP11 unit O1 tributaries ? #328 
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The batch stream that executes after all SYSGEN dialog questions are 
answered will instruct you to mount the DECnet/E distribution medium on 
a device unit. It may be necessary to dismount the RSTS/E distribution 
medium in order to mount the DECnet/E tape or disk. Later in the batch 
stream, you would remount the RSTS/E medium. 


Following the system generation procedure, you should use the RSTS/E sys- 
tem initialization program (INIT.SYS) to tailor the system to your oper- 
ation. (See the RSTS/E System Generation Manual for details on running 
INIT.SYS.) The following DECnet/E requirements should be taken into 
consideration: 


e Full routine nodes require space from the extended buffer pool (XBUF) 
for the routing matrix and other routing data structures. This is inde- 
pendent of other XBUF usage and must be added to other requirements to 
determine the total XBUF size. The amount of additional space needed is 
determined by the node’s maximum number of circuits and the maximum 
node address for the network: 


words of XBUF = (maximum circuits) * (maximum node address) 
+ maximum circuits 
+ 2* (maximum node address) 
+ 32 


e Like the RSTS/E spooler programs, the DECnet/E library programs 
require a job area larger than 8K. Always set SWAP MAX to at least 
28K. 


@ Use the SET PRIV option to disable nonprivilaged access to any DMP and 
DMV controllers. If you do not want your DMC and DMR controllers 
available for use by non-DECnet jobs, use the SET PRIV option to restrict 
access to them also. 


1.3 Building the DECnet/E Library 


Before building the DECnet/E library, you must build the following RSTS/E 
modules: RSX and RMS. (See the RSTS/E System Generation Manual for 
the details of this procedure.) Certain RSX utilities (such as TKB) are 
required to build the DECnet utilities; NCP and NML must run under the 
RSX Run-Time System; and RMS is required by NFT and FAL. 


After these modules are built, be sure the DECnet/E distribution medium is 
mounted. It may be necessary to dismount the RSTS/E library medium used 
in the previous build and replace it with the DECnet/E distribution 
medium. 


When the distribution medium is mounted, run the RSTS/E BUILD pro- 
gram and answer the appropriate questions. 


e@ The source input device is your DECnet/E Distribution device. 
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e The target library account is ordinarily user account [1,2] on device SY: 
— the RSTS/E system library. Task images of the network programs are 
installed in this account. It is possible, of course, to designate an account 
other that SY0:[1,2] as the DECnet library. However, if you do so, you 
must edit the configuration and verification control files and the DECnet 
startup command file to access the proper account. The existing com- 
mands to install and run the network programs will no longer work since 
they use the “$” account designator, specifying the RSTS/E system 
library (e.g., “RUN $NFT”). 


@ The control file is DECNET.CTL from account [1,2] on the distribution 
device. (Note that when this file is copied from the distribution device to 
the target system device, it is renamed to BLD01.TMP.) 


e The function is either BUILD or BUILD/PATCH, depending on whether 
or not there are DECnet/E patches. (Patches to DECnet/E are included in 
the quarterly RSTS/E autopatch distribution. Before executing the build 
procedures here, :ou should copy the DECnet/E patch files from the patch 
kit distribution device to SY:[200,200]. See the RSTS/E documentation 
for details on how to dv this.) 


@ The question concerning NFT and FAL should be answered “RLB” if RMS 
has been installed as a resident library; otherwise, it should be answered 
“OVL”. 


Answer all other questions with a linefeed ©. 


The following example shows a typical DECnet/E build sequence, including 
patches. MMO: is the distribution device, and NFT and FAL are to be built 
as overlays. 


RUN $BUILD 

BUILD V7.1-07 RSTS 1T7,1-07 

System Build <No> ? 

Source Input Device <S¥:> ? MMO: 
Library Output Device <SY¥:> ? 
Target System Device <SYO:> ? 
Library Account ¢Ci1,s21]> ? 

Control File is ? MMO:C1+2] DECNET.CTL 


*#** Copying file MMO:C1+2] DECNET.CTL to BLDO1.TMP *#** 


Function (Build/Patch»s Patch» Build) <Build/Patch> ? BUILD/PATCH 
Patch File Input Location ¢<SY:[200,2001]> ? 
Run-Time System <CRSX1> ? 
Do you want NFT and FAL built to use: 
RSX Run-Time System and the RMS Resident Library ‘RLB’ 
RSX Run-Time System with disk overlays ‘’OVL’ 
Build NFT/FAL using <OVL> ? 
Additional Control File is <None> ? 


*** Processing Started on 31-SEP-81 at 13:47 PM *x%% 
NOTE 


You can execute the procedure described here using the 
DAPBLD.CTL control file from the DECnet/E distribution 
medium to rebuild just the file transfer software. This can 
be done if a new release of RMS is installed. 
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Chapter 2 
Network Configuration 


Before starting DECnet/E for the first time, you must set up the permanent 
parameter file (S$ NETPRM.SYS) to reflect the configuration of your network. 
This configuration process consists of the following steps: 


1. Constructing the configuration control file containing the necessary NCP 
commands (see Section 2.1). 


2. Running the control file to define values in $NETPRM.SYS (see Section 
2.3). 


3. Listing the network parameters to verify that the configuration was done 
correctly (see Section 2.3). 


After the permanent parameter file is configured, you must run through the 
installation verification procedures (described in Chapters 3 and 4) to 
ensure that the communications hardware is functional and that all sup- 
ported adjacent nodes are reachable. Once these procedures are complete, 
you can tailor the permanent parameter file to facilitate daily operation and 
include the network startup command file in the RSTS/E initialization pro- 
cedure (see Section 2.4). 


2.1 Constructing the Network Configuration Control File 


The manner in which the configuration control file is constructed depends on 
whether or not you are currently using DECnet/E V1.1 to operate your node. 


If you have not been using DECnet/E V1.1, print out the control file 
(NCPDEF.CTL) from the DECnet/E distribution kit. (Also see Appendix 
A.1.) This is a model configuration control file containing prototype NCP 
commands defining a general network environment. Edit this file to include 
information about your own system. For instance, you will want to use your 
own system’s node name and number as the EXECUTOR node name and 
number. Comments within the model file and the information found in Sec- 
tion 2.2, “Node Generation Guidelines,” will help you determine what modi- 
fications need to be made. 


If you have already been using DECnet/E V1.1, the procedure for construct- 
ing the configuration control file is as follows: 


1. Copy the NCU.SYS file from your V1.1 system. 


2. Run the DECnet/E V2.0 conversion utility, NCUCVT, using your old 
NCU.SYS file as input. This utility generates an output file containing 
the NCP commands that will recreate your Version 1.1 configuration on 
the Version 2.0 system. 


Since the model configuration control file supplied in the distribution kit 
is named NCPDEF.CTL, for the remainder of this discussion it is 
assumed that the name of the NCUCVT output file is also 
NCPDEF.CTL. The file can be named anything you wish, but if you do 
use the name NCPDEF.CTL, the distribution copy will be overwritten. If 
you wish to retain the distribution copy, you must either rename it with 
PIP (the Peripheral Interchange Program) before beginning NCUCVT 
execution or supply a different name for the NCUCVT output file. (See 
the RSTS/E System User’s Guide for instructions on using PIP.) 


3. Print NCPDEF.CTL and read it. It also contains commands defining cer- 
tain Phase III parameters that are not applicable to your Version 1.1 sys- 
tem. If you wish, edit this file to change Version 2.0 defaults or to modify 
your existing Version 1.1 configuration. If you have DMP or DMV 
devices, add definitions for those lines, as described in the DECnet/E Sys- 
tem Manager’s Guide. 


NCPDEF.CTL defines an unprivileged default account — [100,100] — for 
use by network programs such as MIRROR, FAL, and NML. It also defines a 
logging file — SY:[1,100JEVTLOG.LOG — for use by the event logger. You 
can use these user accounts or specify others by editing the control file. 
Either way, be sure that the accounts specified exist. If they do not, create 
them using the RSTS/E REACT utility. (See the RSTS/E System Manager’s 
Guide for detail on using REACT.) 


Note that logging to the console (default KB0:) is enabled by NCPDEF.CTL 
to permit you to see events as they happen during network installation, and 
file logging is enabled to provide a record for your software specialist in case 
of problems. Under normal circumstances, you may not wish to see this level 
of logging detail but it is necessary during installation verification pro- 
cedures. Do not edit it out of the configuration control file until installation 
verification is complete. 
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Certain guidelines should be followed when configuring a DECnet/E node in 
a network. Aside from observing basic minimum and maximum values and 
ensuring that related parameter values are consistent with one another (see 
Section 3.1), you must choose certain network parameters carefully to avoid 
network routing problems. 


The following subsections discuss the guidelines that should be followed 
when specifying network parameter values with the SET EXECUTOR com- 
mand. (See the DIGITAL Network Architecture, Transport Functional Speci- 
fication for a general discussion of the Phase III routing algorithm and the 
details of how each network parameter affecting routing is used.) 


2.2.1 Specifying Maximum Circuits 
The executor parameter MAXIMUM CIRCUITS serves two purposes: 
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1. It controls whether your DECnet/E system will initialize itself (at start- 
up) as an end (nonrouting) node or as a routing node. 


2. It controls the maximum number of circuits that can be turned on 
simultaneously. 


A Phase III end node, by definition, has only one circuit, connecting it to one 
adjacent node in the network. Only network traffic to or from that node’s 
own users and software occurs over the circuit. 


A Phase III routing node, on the other hand, has more than one circuit, con- 
necting it to multiple adjacent nodes in the network. Aside from receiving 
and transmitting its own network traffic, a routing node forwards data pack- 
ets from other nodes. Because of this service function, a routing node must 
maintain a list of all nodes in the network, along with the identity of the 
physical line by which they can be reached. This routing table is maintained 
in the extended buffer pool (XBUF). Thus, DECnet/E support of a routing 
node uses more system resources — both memory space and processing time 
— than an end node. (For further information, see the DECnet/E System 
Manager’s Guide.) 


If your system is small or heavily used, you should consider configuring it as 
an end node. In a full Phase III network, you would still have access to all 
other nodes in the network as long as the adjacent node to which your single 
circuit is connected is a routing node and can perform data forwarding ser- 
vices for you. (Note that two connected end nodes will comprise an isolated 
two-node network.) 


Setting the executor parameter MAXIMUM CIRCUITS equal to one causes 
your node to initialize itself as an end node; setting MAXIMUM CIRCUITS 
to a value greater than one causes the node to initialize itself as a routing 
node. Since this parameter defines the dynamic configuration of the 
DECnet/E software, it cannot be changed once the network is started. It can, 
however, be changed between network startups without repeating the SYS- 
GEN process. Thus, your system could be a routing node one day and an end 
node the next. 


The MAXIMUM CIRCUITS parameter also controls the number of circuits 
that can be turned on at one time. You can have more physical lines (or 
tributaries in a multipoint environment) on your system than the MAX- 
IMUM CIRCUITS parameter specifies, but only that number can be turned 
on simultaneously. 


2.2.2 Specifying Maximum Hops 


The executor parameter MAXIMUM HOPS controls the length of the rout- 
ing path that a data packet can take to its destination. 


If you draw a map of your entire network, showing all physical lines con- 
necting the nodes, it is possible to count the number of hops it takes to get a 
data packet from one node to any other node in the network. (A hop is the 
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path between two adjacent nodes — along a single circuit — no matter how 
long or how fast.) A routing path is a series of hops from a data packet’s 
source to its destination; the length of the path is the number of hops. The 
network diameter is the length of the longest routing path. In general, the 
MAXIMUM HOPS parameter should have a value no less than this network 
diameter. 


The routing software calculates the path length from the local node to every 
other node in the network. If the path length to any remote node is greater 
than MAXIMUM HOPS, that remote node is considered unreachable and 
the local node will be unable to communicate with it or forward data to it. 


2.2.3 Specifying Maximum Cost 


The executor parameter MAXIMUM COST controls the total cost of a rout- 
ing path. 


Each circuit on a node has a certain cost associated with it at that node. Cost 
is an arbitrary number, assigned in such a way that the routing software 
will prefer certain paths to others. The routing software chooses a path with 
minimum cost. The total cost of a routing path is the sum of the costs of each 
circuit on the path, as assigned at the node on the transmitting end of the 
circuit. 


The MAXIMUM COST parameter is like the MAXIMUM HOPS parameter; 
if the cost of a routing path from the local node to another node in the net- 
work is higher than the MAXIMUM COST value, the remote node is consid- 
ered unreachable. Thus, each node should have a MAXIMUM COST value 
no less than the maximum path cost of the entire network. 


2.2.4 Specifying Maximum Visits 


The executor parameter MAXIMUM VISITS controls the number of nodes 
through which a data packet can travel from its source to its destination. 


Included in the header portion of each data packet is a counter of the num- 
ber of nodes through which the packet has traveled. The Phase III routing 
software increments this counter each time the packet is forwarded to 
another node. If the counter exceeds the MAXIMUM VISITS parameter at a 
forwarding node, the data packet is discarded and a logging message is 
output: 


Event type 4,0» Aged Packet loss 
Occurred O3-AUG-81 16:09:32.2 on node 140 (ARK) 
Packet header = 4 135 140 A 


If a line goes down on the minimum routing path, the software automati- 
cally chooses a new path if it can, possibly causing packets already in transit 
to back track through nodes they have already visited. Thus, the MAX- 
IMUM VISITS parameter should be set high enough to permit a certain 
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amount of this type of routing activity, but low enough to catch packets 
caught in a loop. The value must be greater than MAXIMUM HOPS and 
should generally be no less than the network diameter — one to one and a 
half times the network diameter is a reasonable guideline. 


2.2.5 Specifying Node Addresses 


The executor parameter ADDRESS sets the local node’s network address. 
Node addresses must be unique across the network. Assigning the same 
address to two different nodes will result in one of two situations: 


1. If the path costs to send messages to the two nodes differ, messages are 
always directed to the node with the lower path cost. 


2. If the path costs to send messages to the two nodes are the same, mes- 
sages are always sent to only one of the nodes. 


In both cases, messages can be received from both nodes but can be sent to 
only one. 


NOTE 


Note that you need not assign node names that are unique 
across the network. To avoid unnecessary confusion, how- 
ever, it is good practice to do so. 


2.2.6 Specifying Maximum Node Address 


The executor parameter MAXIMUM ADDRESS defines the size of your 
network. Node addresses are assigned in the range of 1 to MAXIMUM 
ADDRESS. Thus, if there are 32 nodes in your network, for example, 
MAXIMUM ADDRESS must be 32 (or more), even if only 20 of those nodes 
are ever on the network at one time. 


The MAXIMUM ADDRESS parameter also determines the size of the rout- 
ing table stored at the local node. To ensure that all routing tables are the 
same length, the same maximum node address should be specified for all 
nodes in a network. 


When the maximum node address specified on one node is larger than that 
specified on an adjacent node, routing information passed between the two 
nodes will be truncated to the smaller address. Information concerning 
nodes with addresses higher than the smaller maximum will be lost and 
those nodes will be unreachable. 


Since the size of the routing data base is determined by the maximum 
address specified, the node with the smaller maximum address will discard 
routing information it cannot store and will generate an event message: 


Event type 4.5» Partial routing update loss 
Occurred O3-AUG-81 16:09:38.2 on node 140 (ARK) 
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If a node name is assigned to a remote node whose address is higher than 
that specified in the routing table, that node will be unreachable. 


2.2.7 Specifying Data Link Segment Size 


The executor parameter BUFFER SIZE sets the maximum size of a data 
segment that the local node will receive over a link. The data link segment 
size should be the same for all nodes on a routing path. This ensures that the 
segment size is large enough for each path in the network. 


When the segment size of an intermediate node is smaller than that of the 

source and destination nodes, a data packet larger than the smaller size will 
be lost on route to its destination. The node adjacent to the node with the 2) 
smaller segment size will refuse to forward the data packet and will output 

an event message: 


Event type 4.3+ Oversized packet loss 

Occurred O3-AUG-81 16:09:42.4 on node 140 (ARK) 
Circuit DMC-0O 

Packet header = 4 135 140 A 


If the node at which the error occurred is not the source, the source will 
observe only a failure to communicate and will not be aware of the nature of [@ | 
the problem. This can be especially confusing since control messages (such 

as the Connect Initiate Message) tend to be much shorter than user data 

messages and, therefore, have a higher likelihood of being transmitted, even 

in the above circumstance. Thus a program could establish a link but not 

necessarily use it. 


2.3 Running the Configuration Control File 2 


After you have constructed the configuration control file, either by editing 
the model supplied in the distribution kit or by running the NCUCVT con- 
version utility, you are ready to create the permanent parameter file. Do 
this by submitting NCPDEF.CTL to the batch processor. During execution 
of this control file, NCP creates the permanent parameter file 
($NETPRM.SYS) and loads it with data according to the DEFINE com- 
mands contained in the file. 


You can type additional DEFINE commands directly to NCP but it is good 
practice to maintain all commands in a single control file that completely 
describes your system. 


When the control file has run to completion, you should examine the net- 
work parameters to ensure that the configuration was done correctly. Use 
the following NCP commands to print out the data now in $NETPRM.SYS: 


2-6 DECnet/E Network Installation Guide 


Cc 


gy 


LIST EXECUTOR CHARACTERISTICS 

LIST KNOWN CIRCUITS CHARACTERISTICS 
LIST KNOWN LINES CHARACTERISTICS 
LIST KNOWN NODES CHARACTERISTICS 
LIST KNOWN OBJECTS CHARACTERISTICS 
LIST KNOWN LOGGING CHARACTERISTICS 


Review the information generated to be sure it is correct. If any of the infor- 
mation is incorrect and you need to rerun the control file, you should first 
use PIP to delete $NETPRM.SYS. This forces NCP to create a new file. Oth- 
erwise, the NCP DEFINE commands will be applied to the previous version 
of $NETPRM.SYS. 


2.4 Final Configuration 


When installation verification procedures are complete, you may want to 
modify the permanent parameter file or the DECnet startup control file to 
facilitate daily operations. (The startup command file (DECNET.CMD) is 
copied from the distribution kit during the DECnet build sequence and con- 
tains commands for loading the permanent parameter file into the volatile 
parameter file and turning on the node. See Appendix A.7.) 


The permanent parameter file is configured with all communication circuits 
in the OFF state. For day to day operations, however, you may want to have 
all or some of the circuits started immediately after the node starts up. Do 
this by editing the startup command file to include a SET CIRCUIT com- 
mand, setting the state of each circuit you want started. These commands 
should be inserted following the SET EXECUTOR STATE ON command 
and have the following format: 


SET CIRCUIT circuit-id STATE ON 


The parameter circuit-id identifies the particular circuit. You could also use 
the SET KNOWN CIRCUITS command to set the state of all circuits: 


SET KNOWN CIRCUITS STATE ON 


These circuits will then be started after the permanent parameter file is 
loaded into the volatile parameter file with the SET SYSTEM command and 
after the SET EXECUTOR STATE ON command is issued. 


Note that the maximum number of circuits that can be turned on at one 
time is determined by the MAXIMUM CIRCUITS parameter of the SET or 
DEFINE EXECUTOR command. If you attempt to turn on more than this 
number, only the specified maximum will be started. NCP will generate 
error messages for the remainder: 


No room for new entry 

Error detail = CIRCUIT 

? No room for user on device 

Error changing line/circuit Parameter 


Network Configuration 2-7 


2-8 


For installation verification procedures, CONSOLE logging and FILE log- 
ging are enabled for all known events. In daily operations you may not want 
this volume or level of detail for event logging. Use the DEFINE LOGGING 
commands to specify the logging sinks to which you want DECnet to log 
events. If your network coordinator wants your system to log events to a cen- 
tral node, define this remote logging sink in the permanent parameter file as 
well. a 


While specifying the logging sinks, you can also set up the filters for each 
sink, defining the types of events each is to receive. Ordinarily all events 
should be logged to the logging FILE. You might, however, want the logging 
CONSOLE to print only selected event messages — line ON/OFF and execu- 
tor ON/OFF messages, for example. (See the DECnet/E System Manager’s 
Guide for a discussion of event logging, logging sinks, and logging filters.) 


Once the startup command file and the permanent parameter file reflect 
your daily operational requirements, you should make one final verification 
that you have done everything correctly. Using the NETOFF utility, shut 
down the node. Run SYSTAT to verify that NSP and the event logger 
(EVTLOG) are no longer running. Check the event logger messages; when 
the node has finally shut down, the following logging message will be 
output: 


Event type 2.0% Local node state change 
Occurred O3-AUG-81 16:09:22.3 on node 140 (ARK) 
Reason for state change: Operator command 

Old node state = On 

New node state off 


After this, submit the final DECNET.CMD command file to the system 
startup control program (INIT.BAS) to restart the node. (See the RSTS/E 
System Manager’s Guide for details on running INIT.BAS.) Use the NCP 
SHOW command to verify that everything is initialized as you want it. Ver- 
ify that the event logger is logging messages to the proper logging sinks. 


When this final configuration has been completed and verified, you may 
want to include the DECnet startup command file as input to INIT.BAS dur- 
ing RSTS/E startup. In this way, DECnet/E will be started automatically 
whenever the operating system is ihitialized. To do this, edit the RSTS/E 
startup command file, START.CTL, to include the following command as 
one of the final steps in system initialization: 


@DECNET.CMD 
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Chapter 3 
Local Node Operation Verification 


When the permanent parameter file has been generated and the parameters 
have been verified to be correct, you must verify the following: 


@ The DECnet/E software at the local node is functioning. 
@ The local communications hardware is operational. 
e Allsupported adjacent nodes are reachable. 


This chapter describes the procedure for verifying the local node. Chapter 4 
describes adjacent node testing. 


NOTE 


During the verification procedures described in this chapter 
and in the following chapter, it is assumed that there is no 
other network activity at the local node. Thus, all event log- 
ging messages and counter activity can be attributed to the 
particular test being run. If, in fact, there is other network 
activity going on at the local node while these tests are 
being run, counters and event logging messages will be 
affected. 


3.1 Starting DECnet/E on the Local Node 


Before running your node in the network for the first time, start up the 
RSTS/E system, without DECnet/E, to ensure that it is operating correctly. 
Use the HARDWARE LIST option of the system initialization program 
(INIT.SYS) to make sure that the necessary communications devices are 
attached. (See the RSTS/E System Generation Manual for details on run- 
ning INIT.SYS.) Next, start up DECnet/E by submitting the startup com- 
mand file (DECNET.CMD) to the system startup control program 
(INIT.BAS). (See the RSTS/E System Manager’s Guide for details on run- 
ning INIT.BAS.) DECNET.CMD contains NCP commands for initializing 
and turning on the node. 


Initializing the node is done with the SET SYSTEM command. This NCP 
command does two basic things: It sets up the volatile parameter file, and if 
the logging state has been defined as ON, it starts the event logger. 


To set up the volatile parameter file, NCP first creates an empty file, using 
either the file specification given with the DEFINE EXECUTOR 
VOLATILE PARAMETER FILE command or a default file specification of 
SY:[0,1]NSPO.SYS. (You can determine the file specification used by issuing 
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the LIST EXECUTOR CHARACTERISTICS command.) After this file is 
created, data from the permanent parameter file ($NETPRM.SYS) is copied 
into it. The volatile parameter file is then installed as a RSTS/E system file. 


If NCP encounters any problems in this sequence, it outputs the following 
message: 


?Can’t SET SYSTEM - 


Another error message is appended to this message giving additional infor- 
mation about the problem. If a problem occurs, the most likely message is 
“System already SET” indicating that the volatile parameter file already 
exists. If this happens, issue the CLEAR SYSTEM command to delete the 
existing file, and resubmit DECNET.CMD to INIT.BAS. 


Other error messages at this point are generally standard RSTS/E file oper- 
ation error messages and are usually self-explanatory. 


The volatile parameter file is installed as a swap file. At the completion of 
the batch run, you should use the UTILTY program to verify that this is the 
case. The LIST SWAPFILES command should display the name of the vol- 
atile parameter file in the following format: 


DECnet/E file: file-specification 


(See the RSTS/E System Manager’s Guide for details on running UTILTY.) 
If you do not see this display, file a Software Performance Report (SPR) or 
contact your software specialist. 


After the volatile parameter file is created and installed, the SET SYSTEM 
command starts the event logger if the logging state has been defined ON. If 
NCP is unable to do this, it outputs the following message: 


?Can’t start event logger 


This message is followed by a RSTS/E standard error message giving addi- 
tional information on the problem. If a problem occurs, this message is usu- 
ally “?File not found.” If so, make sure that the event logger task file 
(EVTLOG.TSK) is located on the same device and in the same account as 
the NCP task file (NCP.TSK). If it is not, use PIP to transfer the file to the 
proper device and account. 


After the node is initialized, it is started with the SET EXECUTOR STATE 
ON command. This command first does consistency checking of the parame- 
ters in the volatile parameter file. If a parameter value is found to be out of 
range or inconsistent with another related parameter, NCP outputs an error 
message followed by an error detail message containing the name of the 
invalid parameter. If this error occurs, correct the DEFINE command for the 
invalid parameter in the configuration control file. (Table 3-1 lists the valid 
ranges of executor, line, and circuit parameters.) 


When the SET EXECUTOR STATE ON command completes successfully, 
an event logging message is output: 
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Event type 2-0» Local node state change 
Occurred O3-AUG-81 15:37:42.5 on node 140 (ARK) 
Reason for state change: Operator command 

Old node state = Off 

New node state = On 


If this message is not output, run SYSTAT to determine whether the event 
logger is running as a message receiver. (See the RSTS/E System User’s 
Guide for information on SYSTAT.) If it is not, the event logger was not suc- 
cessfully spawned as a job during the SET SYSTEM sequence. (The RSTS/E 
Spawn Job function does not return any status to the calling job, and thus, 
NCP has no way of knowing whether or not the event logger was, in fact, 
started.) Issue the SET ALL LOGGING STATE ON command and recheck 
the event logger status with SYSTAT. If the event logger is still not run- 
ning, contact your software specialist. 


Table 3—1: Executor, Line, and Circuit Parameter Constraints 


PARAMETER NAME RESTRICTIONS 
Executor Parameters 
Incoming Timer Greater than 0 
Outgoing Timer Greater than 0 
Maximum Links Greater than 0 
Delay Factor Greater than 0 
Delay Weight Greater than 0 
Inactivity Timer Greater than 0 
Retransmit Factor Greater than 0 
Routing Timer Greater than 0 
Maximum Address Greater than or equal to the EXECUTOR address 
Maximum Circuits Greater than 0; less than or equal to 16 
Maximum Cost Greater than MAXIMUM HOPS; less than 255 
Maximum Hops Greater than 0 
Maximum Visits Greater than MAXIMUM HOPS 
Maximum Buffers Greater than or equal to 3 
Buffer Size Greater than or equal to 246; less than or equal to 568; 
same on all nodes throughout the network 
Date Xmit Queue Max Greater than or equal to 8 
Int/LS Queue Max Greater than or equal to 8 
NOTE 


The size of the routing matrix maintained by the Transport module is 
determined by MAXIMUM CIRCUITS and MAXIMUM ADDRESS: 
Routing matrix = (MAX CIRC)*(MAX ADDR). This value must be less 
than or equal to 4060. 


Line Parameters 


Receive Buffers Greater than or equal to 3; less than or equal to 32 


(continued on next page) 
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Table 3-1 (Cont.): Executor, Line, and Circuit Parameter Constraints 


PARAMETER NAME RESTRICTIONS 


Circuit Parameters 


Cost Greater than 0; less than or equal to 25 
Hello Timer Greater than or equal to 1; less than or equal to 65535 
Tributary Greater than 0 for multipoint circuits 
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The DECnet/E distribution kit includes a batch control file (NTESTE.CTL) 
for testing the local node software (see Appendix A.2). This file contains 
NCP commands to do the following: 


e Perform internal loopback tests that verify local data transfers through 
the Transport layer. 


@ Show local node counters, both before and after the loopback tests. 
@ Run NFT to verify local data transfers and job spawning capabilities. 
No communication lines need to be turned on to run these tests. 


Before using NTESTE.CTL, edit it as specified in the file comments to insert 
the name of your local node and to supply the necessary password informa- 
tion. When this is done, submit the control file to the batch processor. 


The first part of the batch control file runs two separate local logical link 
loopback tests. The first test uses the LOOP EXECUTOR command to create 
a logical link between the local NCP program and the local MIRROR pro- 
gram. The second test uses the TELL prefix to execute the LOOP NODE 
command, specifying the local node name as the destination node. This cre- 
ates two logical links — one between the local NCP program and the local 
Network Management Listener (NML) and another between NML and the 
local MIRROR program. 


NOTE 


These commands assume that a default account has been 
defined for the MIRROR program at the local node with the 
SET/DEFINE EXECUTOR DEFAULT ACCOUNT com- 
mand. If this is not the case, edit the control file to supply 
accounting information with the LOOP command. 


If any of these logical links cannot be created, or if a link fails after the con- 
nection sequence has completed, NCP will output an error message 
indicating the program to which the attempted link failed (either the Lis- 
tener (NML) or the MIRROR program). This message is followed by an error 
detail message giving further information. Table 3-2 lists the various error 
detail messages for these connect failures and the action that you should 
take if the error occurs. 
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Table 3-2: Local MIRROR Connect Failures 


Value Standard Text Action 

0 No node name set File an SPR. 

1 Invalid node name format File an SPR. 

2 Unrecognized node name File an SPR. 

3 Node unreachable File an SPR. 

4 Network resources Verify that various network parameters (e.g., 
maximum links, transmit queue sizes) have been 
adequately defined. 

5 Rejected by object File an SPR. 

6 Invalid object name format File an SPR. 

7 Unrecognized object Verify that 


NML = object 19 
MIRROR = object 25 
8 Access control rejected Verify that access control information has been 
specified correctly in the control file or with the 
SET/DEFINE EXECUTOR DEFAULT 
ACCOUNT command; verify that the account 


exists. 
9 Object too busy File an SPR. 

10 No response from object File an SPR. 

11 Remote node shut down File an SPR. 

12 Node or object failed File an SPR. 

13 Disconnect by object File an SPR. 

14 Abort by object File an SPR. 

15 Abort by Management Someone aborted the link with the ABORT LINK 
command; restart the test. 

16 Local node shut down Verify the node state with the SHOW EXECU- 


TOR STATE command; restart the node. 


The control file executes the SHOW EXECUTOR COUNTERS command 
before and after each loopback test is run. At the completion of each of the 
tests, you should see the following changes in the counters: 


e The number of messages received and sent should increase by 2 times the 
value of the COUNT parameter in the LOOP command. 


e The number of bytes received and sent should increase by 2 times the 
value of the COUNT parameter, multiplied by the length of the loopback 
message. (The length of the loopback message is determined by the 
LENGTH parameter in the LOOP command. If none is specified, a default 
value of 128 bytes is used.) 


e The number of connect requests received and sent should increase by 
either one or two, depending on whether the LOOP EXECUTOR or TELL 
nodename LOOP NODE command was executed. 


If any of these counters is incorrect, or if the test itself generated an error 
message indicating a bad loopback response, file a Software Performance 
Report (SPR) or contact your software specialist. 


The node counters displayed with the SHOW EXECUTOR COUNTERS 
command also include certain error counters (e.g., “response timeouts” or 
“resource errors”). A nonzero value for any of these counters generally 
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indicates that various network parameters, such as the queue sizes or the 
timeout delay weight and delay factor, have not been defined adequately. 
Use the LIST EXECUTOR CHARACTERISTICS command to display the 
current network parameters, and then verify that the values are appropri- 
ate. Refer to the Appendix B of the DECnet/E System Manager’s Guide and 
to Section 2.2 of this manual for guidelines to follow when defining your 
local node parameters. 


The length of time that it takes to run these loopback tests depends upon the 
values of the COUNT and LENGTH parameters supplied with the LOOP 
command. An absolute time frame cannot be supplied. However, if it seems 
to you that the tests are taking an unusual amount of time, it is possible to 
monitor the test activity from another terminal. 


@ Type the NCP SHOW ACTIVE LINKS command. You should see two or 
four active links, depending on whether the LOOP EXECUTOR or the 
TELL nodename LOOP NODE command is being executed. (Each link is 
listed twice, once for each program on the link.) 


e Run SYSTAT. The MIRROR program should be running and should be a 
declared receiver. 


e@ Type the NCP SHOW EXECUTOR COUNTERS command two or three 
times. You should see the count of messages and bytes incrementing. 


The final part of the local software verification tests consists of running the 
Network File Transfer program (NFT) to copy a file within the local node. 
This verifies that NFT and the File Access Listener (FAL) have been 
installed properly and that FAL can be started automatically as the result of 
an incoming request for a logical link connection. 


If the file transfer software has been built and installed properly, it is 


located in the DECnet library, as specified during the build procedure (see, 


Section 1.3). This is usually the RSTS/E system library — account [1,2] on 
the system disk — but can be any account the system manager specifies. 
Remember, however, that specifying a user account other than [1,2] will 
require changes to the distribution control files that install and run the net- 
work programs; the existing control files use the “$” account designator 
(specifying the system library). 


If the system monitor is unable to locate the file transfer software, the fol- 
lowing RSTS-standard error message will be generated when the batch con- 
trol file attempts to run NFT: 


?Can’t find file or account 


If this error message is output, use PIP to verify that the NFT task image 
file is, in fact, located in the same account being accessed by the batch con- 
trol file. (See the RSTS/E System User’s Guide for information on using 
PIP.) Also use the NCP SHOW KNOWN OBJECTS command to verify that 
FAL has been defined for automatic startup as object 17. If everything seems 
to be in order, but the file transfer software still cannot be run, file an SPR or 
contact your software specialist. 
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After the programs are started and the logical link is established, the batch 
control file (NTESTE.CTL) is copied to a temporary file in another account 
on the local node. From there, it is output to the batch logging file (or to the 
console if you are not using BATCH). The temporary file is then deleted. If 
the file is not output as expected and any failure conditions reported by NFT 
are not easily explained and corrected, file an SPR or contact your software 
specialist. (See the DECnet/E Guide to User Utilities for a list of NFT error 
messages.) 


3.3. Local Node Hardware Verification 


The DECnet/E distribution kit includes a batch control file (NTESTH.CTL) 
for testing the local node hardware (see Appendix A.3). This file contains 
NCP commands that do the following: 


e Turn on the communication devices. 
e Perform hardware loopback tests. 
© Show node and curcuit counters, both before and after the loopback tests. 


The control file is divided into two sections, with each section executing a 
different type of hardware loopback testing. The first section performs a con- 
troller-level loopback test to verify that the device can be turned on and that 
the firmware can transfer data properly. The second section performs a 
hardware-level loopback test to verify that the physical line is operating. 
Before submitting the control file to the batch processor, you must make the 
hardware adjustments necessary for the hardware-level testing. (See 
Appendix C for the details on how to do this.) These adjustments do not 
interfere with the controller-level tests. You must also edit the control file to 
include the name of your local node and the name of the communication 
device to be tested. The test must be duplicated for each device on the local 
system. 


As mentioned in Appendix C (see Section C.2.2), it may be necessary to run 
several hardware-level loopback tests, moving the loopback point progres- 
sively further out each time, to completely test a particular line. If so, dupli- 
cate the hardware-level loopback section of the control file, or separate the 
file into two pieces and run the second section as many times as required. 


When the file is edited and the hardware is configured properly, submit the 
control file to the batch processor. At the beginning of each test, the circuit 
being tested should be in the OFF state. 


NOTE 


If you have been running DECnet/E V1.1 and are certain 
that your communication hardware is working properly, 
you can delete the section of the control file that runs hard- 
ware-level tests. You should, however, run at least one con- 
troller-level loopback test to verify that the Transport 
module and the device driver software are operating 
correctly. 
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The procedure followed in each section of the control file is basically the 
same, and the results of each test can be examined in exactly the same 
fashion. 


The first step in each section is to condition the line for testing. (See Section 
C.1 for details on conditioning a line and the command sequence used for 
each type of loopback test.) After this the circuit is turned on with the SET 
CIRCUIT STATE command. This command first does consistency checking 
on the line and circuit parameters. If any values are out of range or incon- 
sistent with other related parameters, the SET CIRCUIT command will fail. 
If this happens, use the SHOW LINE CHARACTERISTICS and SHOW 
CIRCUIT CHARACTERISTICS commands to determine which parameter 
is in error. (Table 3-1 lists the valid ranges of line and circuit parameters.) 
Correct the parameter value with the DEFINE command and resubmit the 
control file. 


After issuing the command to turn the circuit on, the control file executes a 
time delay to permit the circuit to initialize. Next, the SHOW CIRCUIT 
STATUS command is issued. The circuit state should be ON and the adja- 
cent node should be the name of the local node. If the state of the circuit is 
still OFF, it is possible that the time delay is not long enough to permit the 
circuit to completely initialize. Change the delay factor in the batch control 
file, turn the circuit off by issuing the SET CIRCUIT STATE OFF command, 
and resubmit the control file. If the circuit is still OFF, it is possible that the 
circuit is not owned by DECnet. Issue the SET CIRCUIT OWNER EXECU- 
TOR command, and then resubmit the control file. 


If the state of the circuit is ON-STARTING, either the line is not full-duplex 
point-to-point, or there is a hardware problem in either the controller loop- 
back feature or in the installation of the loopback connector (depending on 
the test being run). Correct the problem, if possible, and resubmit the con- 
trol file. (As noted in Appendix C (see Section C.2.1), if the circuit cannot be 
configured for full-duplex communication to the remote system, you cannot 
perform certain hardware-level loopback tests.) 


When the circuit has initialized and changed state, an event message is 
generated. 


After the circuit is on and initialized, the control file defines a temporary 
loopback node name to the circuit. If this fails, NCP will generally output 
one of the following error messages: 


?Resource error 


or 


?Duplicate node name 
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A resource error usually indicates that NCP could not get enough space 
from the RSTS/E small buffer pool to create the dynamic data structures 
necessary for the temporary node name. Since the number of buffers in the 
small buffer pool is related to overall system loading, you should simply 
wait a short time, reset the circuit state to OFF, and resubmit the control 
file. 


If the error message output indicates a duplicate node name, issue the 
SHOW KNOWN NODES command to determine which node names and 
aliases are currently in use. Edit the control file so that the SET NODE CIR- 
CUIT command that creates the temporary loopback node name specifies a 
name that is not being used. Reset the circuit state to OFF, and resubmit the 
control file. 


Once the temporary loopback node name is defined, the control file issues 
the SHOW NODE COUNTERS and the SHOW CIRCUIT COUNTERS com- 
mands to display the current node and circuit counters. It then executes the 
actual loopback test. The LOOP command issued to execute the actual loop- 
back test assumes that a default account has been defined for the MIRROR 
program at the local node with the SET/DEFINE EXECUTOR DEFAULT 
ACCOUNT command. If this is not the case, edit the control file to supply 
accounting information with this command. 


When the test has completed, the node and circuit counters are displayed 
again. You should see the following changes in the counters: 


Node counters 


e The number of messages received and sent should increase by 2 times the 
value of the COUNT parameter in the LOOP command. 


e The number of bytes received and sent should increase by 2 times the 
value of the COUNT parameter multiplied by the length of the loopback 
message. (The length of the loopback message is determined by the 
LENGTH parameter in the LOOP command. If none is specified, a default 
value of 128 bytes is used.) 


e The number of the connect requests received and sent should increase by 
one. 


Circuit counters 


e The arriving packets received and departing sent should increase by a 
value equal to, or a multiple of, the COUNT parameter in the LOOP 
command. 


e The data blocks received and sent should increase by a value equal to, ora 
multiple of, the COUNT parameter in the LOOP command, plus some 
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small additional amount (5 or 6) representing logical link overhead (Con- 
nect Initiate Messages, and so on). 


¢ The number of bytes recieved and sent should increase by 2 times the 
value of the COUNT parameter, multipled by the length of the loopback 
message, plus some additional amount (approximately 30 times the 
COUNT parameter) representing logical link overhead (acknowledg- 
ments, and so on). 


If any of these counters are incorrect, or if the test itself generated an error 
message indicating a bad loopback response, file a Software Performance 
Report (SPR) or contact your software specialist. 


The counters displayed also include certain error counters (e.g., “response 
timeouts” or “congestion loss”). A nonzero value for any of these counters 
generally indicates that various network and circuit parameters have not 
been adequately defined. Use the LIST NODE CHARACTERISTICS and 
LIST CIRCUIT CHARACTERISTICS commands to display the current 
parameters. Refer to Appendix B of the DECnet/E System Manager’s Guide 
and to Section 2.2 of this manual for guidelines to follow when defining local 
node and circuit parameters. 


The final steps in the testing sequence consist of clearing the temporary 
loopback node name, turning the circuit off, and resetting the circuit con- 
troller mode to NORMAL. If the line being tested normally operates in half- 
duplex mode, you should then issue a SET LINE DUPLEX HALF command. 
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Chapter 4 
Adjacent Node Testing 


Once you have determined that the local node software and hardware are 
operating correctly, you must ensure that the connections to all adjacent 
nodes have been established and that you can transfer data between the | 
local node and all its neighbors. Note that in this chapter we are discussing 
logically adjacent nodes, where a logically adjacent node is defined as a node 
to which direct connections can be established without routing through 
another node. For multipoint tributaries, only the control station is consid- 
ered to be a logically adjacent node. Other tributaries on the same multi- 
point line are not considered adjacent to each other. All tributaries are 
adjacent to the control station, however. 


Before the procedures described in this chapter can be executed, all commu- 
nication lines to be used must pass the local loopback tests described in 
Chapter 3. Also, all adjacent nodes must be operating correctly. If you are 
installing DECnet on multiple nodes of your network, you should install one 
node at a time, completely testing the local hardware and software of each 
node before installing the next. If no nodes in the network are currently 
known to be operating DECnet correctly, you should run all the local tests 
specified in Chapter 3 on each of two nodes before attempting to connect 
them. 


The DECnet/E distribution kit contains three batch control files for testing 
the connections to adjacent nodes: 


NTESTA.CTL For adjacent Phase III nodes (Appendix A.4) 


NTEST2.CTL For adjacent Phase II nodes running DECnet/E V1.1, 
DECnet-RT V1.1, and DECnet-20 V2.0 (Appendix A.5) 


DTSDTR.CTL For adjacent Phase II nodes not running one of the DEC- 
net implementations mentioned above (Appendix A.6) 


You must run one of these files for each adjacent node. Be certain to remove 
any loopback connectors installed during local hardware verification. 


All the procedures described here are designed to be initiated and executed 
from the local node. However, an operator should be present at each remote 
node to handle problem isolation. To facilitate problem isolation for remote 
loop testing, ask the remote operator to enable event logging on his node if it 
has logging capabilities. (Phase II nodes and some Phase III nodes do not.) 


Before testing the connection to an adjacent node, you must know whether 
the node in question is a Phase II or a Phase III DECnet node, and if it is a 
Phase II node, what DECnet implementation it is running. If you do not 
already know this information, ask either the network manager or the sys- 
tem manager of the adjacent node. 


When you have determined the phase and implementation of each of the 

nodes adjacent to your local node, edit the appropriate file for each node with QO 
which you want to test connections. Do this by making the necessary num- ‘ 
ber of copies of each control file or by duplicating the test sections within the 

file itself. Insert the name of the local node, the name of the communication 

device, the name of the adjacent node, and any accounting information 

necessary. 


NOTE 


The LOOP commands in the control files that execute the 
actual loopback tests assume that a default account has 
been defined for the looper program at the remote node. 
If this is not the case, edit these commands in the control 
file to supply accounting information with the LOOP 
command. 


4.1 Tests with Remote Phase Ill Nodes >) 


You test connections with adjacent Phase III nodes using batch control file 
NTESTA.CTL from the DECnet/E distribution kit. This file contains NCP 
and system level commands to do the following: 


e@ Turn on the curcuit to the node. 

@ Show the status of the circuit and of the adjacent node. 

e Run remote node loopback tests that test the software of both nodes. 9 
@ Show node and circuit counters, both before and after the loopback tests. 

@ Run NFT to copy a file to and from the adjacent node. 


Two types of remote node loopback tests are run with each adjacent Phase 
III node. The first test creates a logical link between the local NCP and the 
local MIRROR program; the loopback data is turned around in the remote 
node Transport layer. eo) 


NOTE 


If the adjacent node is not a routing node, the remote Trans- 
port software will not forward messages back to the local 
node. Thus, this first test will fail and the following mes- 
sage will be output: 


MIRROR connect failed -- Node unreachable 


The second test creates a link between the local NCP and the remote 
MIRROR program; in this case, the loopback data is turned around by the 
MIRROR program in the remote node User layer. Verification of both these 
tests follows basically the same procedure as that followed for local hard- 
ware verification (see Section 3.3). 9 
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Before submitting the control file to the batch processor, be sure that all 
loopback connectors installed during hardware verification have been 
removed and that the circuit to the remote node is in the OFF state. 


The first step in the control file sequence is to turn the circuit on with the 
SET CIRCUIT STATE command. This command first does consistency 
checking on the line and circuit parameters. If the command fails because a 
parameter value is invalid, correct the parameter as described in Section 
3.3, and resubmit the control file. 


After turning the circuit on, the control file executes a time delay to permit 
the circuit to completely initialize. It then issues the SHOW CIRCUIT 
STATUS command. At this point, the circuit state should be ON and the 
adjacent node should be the name of the node with which you are testing. As 
with local node hardware verification described in Section 3.3, if the state of 
the circuit is still OFF, it is possible that the control file’s time delay is too 
short. Change the delay factor in the control file, turn the circuit off by 
issuing the SET CIRCUIT STATE OFF command, and resubmit the control 
file. 


If the state of the circuit is ON-STARTING, check for an event logging mes- 
sage indicating that the circuit has gone down or has failed to initialize. The 
event message contains further explanatory information. Correct the prob- 
lem, turn the circuit off by issuing the SET CIRCUIT STATE OFF com- 
mand, and resubmit the control file. 


Once the circuit is on and initialized, the control file defines a temporary 
loopback node name to the circuit and issues the LOOP command. This runs 
a loopback test with the remote Transport layer, creating a link with the 
local MIRROR program. (If the definition of the loopback node name fails, 
see Section 3.3. If the link connection to the local MIRROR program fails, 
see Section 3.2.) 


Node, circuit and executor counters are displayed, both before and after the 
loopback test. In addition, node counters are displayed for both the actual 
node and for the loopback node. The circuit counters and the loopback node 
counters should be verified in the same way as for local hardware veri- 
fication (see Section 3.3). In this case, however, error counters for the circuit 
do not necessarily indicate problems with the definition of circuit parame- 
ters. They can indicate “noise” on the line (that is, electrical interference) or 
buffer shortages at the remote node. 


Assuming there is no other network activity between the two nodes, the 
executor counters and the adjacent node counters should show no traffic. 
However, as discussed in Sections 3.2 and 3.3, various error counters may 
indicate that certain network parameters have been inadequately defined. 
Display the parameters of each node, and refer to Appendix B of the DEC- 
net/E System Manager’s Guide and to Section 2.2 of this manual for guide- 
lines to follow when defining network parameters. 


After the counters are displayed, the control file clears the temporary loop- 
back node name and then issues another LOOP command. This runs the sec- 
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ond loopback test, creating a logical link between the local NCP and the 
remote MIRROR program. If this link cannot be created, or if it fails after 
the connection sequence has completed, NCP outputs an error message. This 
message is followed by an error detail message giving further information 
on the reason for the failure. Table 4—1 lists the various error detail mes- 
sages and the action that you should take if the error occurs. 


Table 4-1: Remote MIRROR Connect Failures 


Value Standard Text Action 
0 No node name set File an SPR. 
1 Invalide node name format Correct the node name specified in the control file. 
2 Unrecognized node name Correct the node name specified in the control file. 
3 Node unreachable Verify that the node address is less than or equal 


to MAXIMUM ADDRESS and that circuit cost is 
less than or equal to MAXIMUM COST; check for 
event logging message, either locally or at the 
remote node, indicating a circuit failure. 


4 Network resources Verify that various network parameters (e.g., 
maximum links, transmit queue sizes) have been 
adequately defined. 

5 Rejected by object Check with the remote system operator for a pos- 


sible explanation of the problem; if none can be 
determined, file an SPR. 


6 Invalid object name format File an SPR. 

7 Unrecognized object Verify that the remote MIRROR program is 
defined as object 25. 

8 Access control rejected Verify that access control information has been 


specified correctly in the control file or with the 
SET/DEFINE EXECUTOR DEFAULT 
ACCOUNT command; verify that the account 
exists. 

9 Object too busy Check with the remote system operator for a pos- 
sible explanation of the problem; if none can be 
determined, file an SPR. 

10 No response from object Check with the remote system operator for a pos- 
sible explanation of the problem; if none can be 
determined, file an SPR. , 


11 Remote node shut down Verify the node state with the SHOW NODE 
STATUS command; have remote operator restart 
the node. 

12 Node or object failed Check with the remote system operator for a pos- 


sible explanation of the problem; if none can be 
determined, file an SPR. 

13 Disconnect by object Check with the remote system operator for a pos- 
sible explanation of the problem; if none can be 
determined, file an SPR. 

14 Abort by object Check with the remote system operator for a pos- 
sible explanation of the problem; if none can be 
determined, file an SPR. 


15 Abort by Management Someone aborted the link with the ABORT LINK 
_comman4; restart the test. 
16 Local node shut down Verify the node state with the SHOW EXECUTOR 


STATUS command; restart the node. 
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Executor, adjacent node and circuit counters are displayed both before and 
after the loopback test is run. You should see the following changes in the 
node and circuit counters: 


Node counters 


e The number of messages received and sent should increase by the value of 
the COUNT parameter in the LOOP command. 


e@ The number of bytes received and sent should increase by the value of the 
COUNT parameter, multiplied by the length of the loopback message. 
(The length of the loopback message is determined by the LENGTH 
parameter in the LOOP command. If none is specified, a default value of 
128 bytes is used.) 


e The number of the connect requests received and sent should increase by 
one. 


Circuit counters 


@ The arriving packets received and departing packets sent should increase 
by a value equal to, or a multiple of, the COUNT parameter in the LOOP 
command. 


@ The data blocks received and sent should increase by a value equal to, or a 
multiple of, the COUNT parameter in the LOOP command, plus some 
small additional amount (2 or 3) representing logical link overhead (Con- 
nect Initiate Messages, and so on). 


@ The number of bytes received and sent should increase by the value of the 
COUNT parameter, multipled by the length of the loopback message, 
plus some additional amount (approximately 15 times the COUNT 
parameter) representing logical link overhead (acknowledgments, and so 
on). 


If any of these counters is incorrect, or if the test itself generated an error 
message indicating a bad loopback response, file a Software Performance 
Report (SPR) or contact your software specialist. 


Again, assuming there is no other network activity between the two nodes, 
the executor counters should show no traffic, but various error counters may 
indicate that certain network parameters have been defined inadequately 
(see Section 3.2). 


The final part of the remote Phase III verification procedure consists of run- 
ning the Network File Transfer program (NFT) to verify that a file can be 
copied between nodes. The batch control file (NTESTA.CTL) is copied to a 
temporary file at the remote node. From there it is copied back to the local 
node and output to the batch logging file (or to the terminal console if you 
are not using BATCH). It is then deleted from the remote node. If the file is 
not output as expected and any failure conditions reported by NFT are not 
easily explained and corrected, file an SPR or contact your software special- 
ist. (See the DECnet/E Guide to User Utilities for a list of NFT error 
messages.) 
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When all tests have been run, the control file turns the circuit off by issuing 
the SET CIRCUIT STATE OFF command. 


4.2 Tests with Remote Phase II Nodes 


4-6 


You test connections with adjacent Phase II nodes using either control file 
NTEST2.CTL or control file DISDTR.CTL from the DECnet/E distribution 
kit. NTEST2.CTL should be used to test connections with Phase II nodes 
running DECnet/E V1.1, DECnet-RT V1.1, and DECnet-20 V2.0. It contains 
NCP and system level commands to do the following: 


e Turn on the circuit to the node. 

@ Show the status of the circuit and of the adjacent node. 
@ Runa Phase II remote node loopback test. 

@ Show node and circuit counters. 

e@ Run NFT to copy a file to and from the adjacent node. 


Phase II remote node loopback tests create a link between the local NCP and 
some type of remote looper program (e.g., the DECnet/E Version 1.1 NCU 
program). The loopback data is turned around by the remote node User 
layer. 


The DTSDTR.CTL batch control file should be used to test connections with 
adjacent Phase II nodes running any supported DECnet product not listed 
above. It contains NCP and system level commands to do the following: 


e Turn on the circuit to the node. 


@ Show the status of the circuit and of the adjacent node. 


Run the DTS/DTR test tool to transfer data to and from the adjacent node. 
(See Appendix E for a discussion of DTS/DTR.) 


e@ Show node and circuit counters. 
@ Run NFT to copy a file to and from the adjacent node. 


Verification of node and circuit counters resulting from these tests follows 
exactly the same procedure as that used for the second portion of Phase III 
remote node loopback testing (see Section 4.1). 


NOTE 


Since Phase II nodes do not include the expanded loopback 
capabilities found in Phase III, the DECnet utility pro- 
grams are used as logical link loopback tools. Table 4-2 
lists the utilities that can be used for this purpose, in 
descending order of preference. The table also reflects their 
availability on each of the supported DECnet products. 
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Table 4-2: Summary of Utility Availability on Remote Nodes 


RSX DECnet DECnet-20 DECnet-RT DECnet-VAX DECnev/E V1.1 


DTS/DTR Yes Yes(2) Yes(1) Yes No 
NFT Yes Yes(3) Yes Yes Yes 
TLK/LSN Yes No Yes No Yes 


(1) DTS is available on Version 1.1 only. 
(2) Available from software specialist. 
(3) Available in DECnet—20 V2. 
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Appendix A 
Distribution Kit Control Files 


A.1 Network Configuration Control File (NCPDEF.CTL) 


$JOB/CCL/NAME=NCPDEF/NOLIMIT/ERROR: FATAL 


$! 

$! Define default configuration for Permanent Parameter file. 
$! 

$RUN $NCP 


! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
| 
| 
! 
! 
! 
! 
! 
! 
! 
! 
! 
| 
! 
! 
! 
! 
! 
! 
! 
\ 
\ 
! 
! 
! 
! 
! 
| 


Pee eT TTS TTT TCTTET TTC TT TTT T TTT TCP TT ee ll 
NCPDEF.CTL Y¥2.0600 

Copyright (C) 1981 by Digital Esuipment Corporations Maynards Mass. 

Edit history: 

2,0600 24-Nov-81 DECnet/E V2.0 Release MLS 

FERRO RRR RO IRIS ETRE TERETE ETE TEE FETE TEE TEE HE TEE TEE HE EE HE 

This file is a prototype NCP command file designed to generate 

a DECnet/E V2.0 node configuration file» ie the Permanent Parameter 

file $NETPRM.SYS. The user should modify this file as indicated 

to define the node’s individual configuration and the surrounding 

network configuration. See the DECnet/E Network Installation Manual 

for further information on the use of this file. The Prototype 

configuration below is used in all Prototype installation test 

command files in this manual, 


ER RRR RRR RR EE FETTER EGET TE ETE FETE TEE FETE TE TET TE TE TE TE TH EE EH HEE EEE EEE 


Prototype local node assumptions: 


ALPHA = your node names ie the executor node name 

1 = the executor node number 

DMR-9O = Point-to-Point device 

DMR-1 = point-to-point device (answers Phone - slow line) 
DMP-9O = multipoint device (master) 

DMP-1 = multipoint device (slave) 


Prototype network node assumptions: 


i) 

BETA = 2 = an addJacent Phase II node via DMR-9O 

GAMMA = 3 = an addacent Phase II node via DMR-1 

DELTA = 4 = an adjacent Phase III tributary via DMP-O 
EPSILN = 5 = an adJjacent Phase III tributary via DMP-0O 
ZETA = 6 = an adjacent Phase III master via DMP-1 
ETA = 7 = a non-adJjacent Phase III node 

THETA = 8 = a non-adJjacent Phase III node 

IOTA = 9 = a non-addjacent Phase III node 

KAPPA = 10 = a non-adJacent Phase III node 

LAMBDA = ii = a non-adJjacent Phase III node 

MU = 12 = a non-adJjacent Phase III node 


! Physical connectivity diagram: 
LPHA -------------------- BETA ------------ MU 


Be Bates heat lett tats LAMBDA: ==-s050c05 KAPPA 


Prototype network Parameters: 
network diameter = 5 (eg DELTA-IOTA Path) 


RRR E HER EEE EEK H EHR EHH IER EK HK EKER KER RHEE EKER EEE ERE EE 
DEFINE PERMANENT PARAMETER FILE command 


This command creates the permanent Parameter file; $NETPRM.SYS. 


DEFINE PERMANENT PARAMETER FILE 
HH EEE EE EERE HEHEHE EEE EEK EKER HEHEHE HEHE EEE EEE EEK HEHEHE EEE KEE HEHEHE EEE HEHEHE EE EEE 


! 

! 

! DEFINE EXECUTOR commands 
! 

! 


These Parameters describe your node, 
| 
DEFINE EXECUTOR ADDRESS 1 
DEFINE EXECUTOR NAME ALPHA 
DEFINE EXECUTOR IDENTIFICATION "DECnet/E V2.0 Prototype" 
DEFINE EXECUTOR ALIAS #LOCAL 
\ 
! These Parameters are based on the network configuration, 
! Constraints: All values } 0 
! MAX CIRCUITS <= 16 
! MAX ADDR >= EXECUTOR ADDRESS 
! MAX VISITS > MAX HOPS 
! MAX COST >= MAX HOPS» and <¢ 255, 
! (MAX ADDR) * (MAX CIRCUITS) <= 4060, 
1 
DEFINE EXECUTOR MAXIMUM CIRCUITS 5 
DEFINE EXECUTOR MAXIMUM ADDRESS 12 
DEFINE EXECUTOR MAXIMUM HOPS 6 
DEFINE EXECUTOR MAXIMUM VISITS 8 


DEFINE EXECUTOR MAXIMUM COST 20 
! 
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1 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 

| 

! 

| 

! 
DEFINE 
DEFINE 
DEFINE 


DEFINE 

DEFINE 
DEFINE 
DEFINE 
I 


These Parameters control local system resource usages 
The buffer size should be the same across the network, 
Constraints: All values > O (except default account not 
BUFFER SIZE >= 246.» and ¢= 568, 
DATA TRANSMIT QUEUE MAXIMUM <= 8, 
INTERRUPT TRANSMIT QUEUE MAXIMUM <= 8, 
MAXIMUM BUFFERS == 3 


EXECUTOR BUFFER SIZE 568 

EXECUTOR DEFAULT ACCOUNT [100,100] 

EXECUTOR MAXIMUM LINKS 32 

EXECUTOR MAXIMUM BUFFERS 16 

EXECUTOR DATA TRANSMIT QUEUE MAXIMUM 8 
EXECUTOR INTERRUPT TRANSMIT QUEUE MAXIMUM 5 


These Parameters control NSP and Transport Processing+s 
Constraints: All values }? 0 


EXECUTOR INCOMING TIMER 120 
EXECUTOR OUTGOING TIMER 120 
EXECUTOR INACTIVITY TIMER 120 
EXECUTOR DELAY FACTOR 48 
EXECUTOR DELAY WEIGHT 3 
EXECUTOR RETRANSMIT FACTOR 5 
EXECUTOR ROUTING TIMER 120 


required) 


KH HHH KH HHH HHH HHH KEE KEKE HEHE KKH HEHEHE KEE E EEE HEHE EHH ERE EEE EERE EE 


These Parameters define your Physical devices, 


! 
! DEFINE LINE commands 
! 
! 
! 


DEFINE 
DEFINE 
DEFINE 


I 

! 

! 

! 
DEFINE 
DEFINE 


DEFINE 
\ 


DEFINE 
é DEFINE 
DEFINE 
DEFINE 
! 
DEFINE 
DEFINE 


DEFINE 


DEFINE 
! 


Constraint: RECEIVE BUFFERS }= 3» and “<= 32, 


LINE DMR-O DUPLEX FULL 
LINE DMR-O VERIFICATION OFF 
LINE DMR-O RECEIYE BUFFERS 4 


Note: the node GAMMA would have its connected device set 
to "VERIFICATION ORIGINATE". 


LINE DMR-1 DUPLEX HALF 
LINE DMR-1 VERIFICATION ANSWER 
LINE DMR-1 RECEIVE BUFFERS 3 


LINE DMP-0 PROTOCOL DDCMP CONTROL 
LINE DMP-0 DUPLEX FULL 

LINE DMP-0 VERIFICATION OFF 

LINE DMP-0 RECEIVE BUFFERS 5 


LINE DMP-1 PROTOCOL DDCMP TRIBUTARY 
LINE DMP-1 DUPLEX FULL 

LINE DMP-1 VERIFICATION OFF 

LINE DMP-1 RECEIVE BUFFERS 4 


! HHH HH KH HHH HH KKK HHH HEE HE HEE KEKE EEE HEHEHE HEHE EEE EEE EEE EEE EKER REE EREE EEE 


DEFINE 


CIRCUIT commands: 


These commands define your logical circuits. 
Constraints: COST >= O»+ and <= 25. 
HELLO TIMER *= 1+ and ¢= 65535. 
If multipoint control or tributary» 
then TRIBUTARY ADDRESS =} 0, 


Distribution Kit Control Files 


A-3 


| 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
I 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
l 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
! 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
{ 
DEFINE 
DEFINE 
DEFINE 
DEFINE 


DEFINE 
! 


DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
DEFINE 
! 

DEFINE 
DEFINE 
DEFINE 
| 


DEFINE 
DEFINE 
! 

DEFINE 
DEFINE 
DEFINE 


DEFINE 
! 


A-4 


CIRCUIT DMR-O OWNER EXECUTOR 
CIRCUIT DMR-O COST 2 

CIRCUIT DMR-O AUTORESTART ON 
CIRCUIT DMR-O HELLO TIMER 15 


CIRCUIT DMR-1 OWNER EXECUTOR 
CIRCUIT DMR-1 COST 3 

CIRCUIT DMR-1 AUTORESTART ON 
CIRCUIT DMR-1 HELLO TIMER GO 


CIRCUIT DMP-0.0 OWNER EXECUTOR 
CIRCUIT DMP-0.0 TRIBUTARY 2 
CIRCUIT DMP-0.0 COST 1 

CIRCUIT DMP-0.0 AUTORESTART ON 
CIRCUIT DMP-0.0 HELLO TIMER 15 


CIRCUIT DMP-0.1 OWNER EXECUTOR 
CIRCUIT DMP-0,1 TRIBUTARY 3 
CIRCUIT DMP-0.1 COST 1 

CIRCUIT DMP-0.1 AUTORESTART ON 
CIRCUIT DMP-0.1 HELLO TIMER 15 


CIRCUIT DMP-1.0 OWNER EXECUTOR 
CIRCUIT DMP-1.0 TRIBUTARY 11 
CIRCUIT DMP-1.0 COST 1 

CIRCUIT DMP-1.0 AUTORESTART ON 
CIRCUIT DMP-1.0 HELLO TIMER 15 


HKEEEKEEEEEEEEE EEE EEE HEHEHE HEHEHE KEE HEHE EERE KHER EKER EERE EKER EEK EE KEE HE KHEHKE KER HEEE 


DEFINE OBJECT commands: 


These commands define the standard DECnet/E obJects, 

They assume that the "$" account (SY:C1+2]) was chosen as 

the DECnet/E package location during the SYSGEN BUILD procedure. 
If a different package location was chosen» the filespecs in 
these commands should be modified accordingly. 


OBJECT 16 NAME LSN 
OBJECT 16 FILE $LSN.BAC 
OBJECT 16 PARAMETERS 29000,;0 


OBJECT 17 NAME FAL 
OBJECT 17 FILE $FAL.TSK 
OBJECT 17 PARAMETERS 07511 


OBJECT 19 NAME NML 
OBJECT 19 FILE $NCP.TSK 
OBJECT 19 PARAMETERS 2900010 


OBJECT 20 NAME NETCPY 
OBJECT 20 FILE $NETCPY.BAC 
OBJECT 20 PARAMETERS 29000;0 


OBJECT 23 NAME NPKDYR 
OBJECT 23 FILE $NPKDYR.TSK 


OBJECT 25 NAME MIRROR 
OBJECT 25 FILE $MIRROR.TSK 


OBJECT 26 NAME EVTLSN 
OBJECT 26 FILE $EVTLOG.TSK 
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DEFINE OBJECT G3 NAME DTR 
DEFINE OBJECT 63 FILE $DTRECY,TSK 
DEFINE OBJECT 63 PARAMETERS 29000 +25600 


| 
© KEKE KEKE EEK EEE KEKE KEE EEE KEE HEE KEE EEE EEE KEE ERE EERE EEE EKER EEE EEE EERE EERE EEEERE 


DEFINE 
DEFINE 
DEFINE 


, 
Cc DEFINE 


DEFINE 
! 

DEFINE 
DEFINE 
! 

DEFINE 
DEFINE 
DEFINE 
DEFINE 


aoe DEFINE 
Q DEFINE 
! 


( DEF INE 
! 
! 
! 
DEFINE 
DEFINE 
DEFINE 
DEFINE 


DEFINE 


DEFINE 
! 


LEER EEE EEE HEHEHE EEE EE KEE KEKE EEE EERE EEE EERE EERE KEKE EERE RHEE KEEKEKRKE RHE KKH HEEE 


! 
$E0D 
$! 
$EQJ 


DEFINE NODE 


commands: 


These commands define the other nodes in the network. 


2 NAME BETA 
NODE BETA ALIAS DATBAS 


If node GAMMA were a DECnet/E node: 

its dial-in line would be VERIFICATION ORIGINATES 
and for its definition of node ALPHA: it would have 
"RECEIVE ORIGINATE PASSWORD WESAYIT" and 

"TRANSMIT ORIGINATE PASSWORD YOUSAYIT",. 


3 NAME GAMMA 
GAMMA RECEIVE ANSWER PASSWORD YOUSAYIT 
GAMMA TRANSMIT ANSWER PASSWORD WESAYIT 


NODE 
Note: 
NODE 
NODE 
NODE 
NODE 4 
NODE 5 
NODE 6 
NODE 6 
NODE 7 
NODE 8 
NODE 9 
NODE 10 
NODE 11 
NODE 12 


NAME 
NAME 


NAME 


DELTA 
EPSILN 


ZETA 


ALIAS MASTER 


NAME 
NAME 
NAME 
NAME 
NAME 
NAME 


ETA 
THETA 
IOTA 
KAPPA 
LAMBDA 
MU 


KEKE HEHEHE EERE KEKE EEE REE KEE EERE KEE HEHEHE KE EERE KRE EEE KEE EEK HEHEHE EKEEKEEEHEE 


DEFINE LOGGING commands: 


These commands control event logger Processing, 


This command causes the event logger to be automatically 
started by NCP when the "SET SYSTEM" command is executed, 


ALL LOGGING STATE ON 


These commands define console and file logging sinks and 
enable active logging to them, 


LOGGING 
LOGGING 
LOGGING 


LOGGING 
LOGGING 
LOGGING 


CONSOLE NAME KBO: 
CONSOLE STATE ON 
CONSOLE KNOWN EVENTS 


FILE 
FILE 
FILE 


NAME SY¥:C1,100]EVTLOG.LOG 
STATE ON 
KNOWN EVENTS 
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A.2_ Local Software Verification Control File (NTESTE.CTL) 


$JOB/CCL/NAME=NTESTE/NOLIMIT/ERROR: FATAL QO 
$! 

Sl KKK HHH KEK HH EK EHEHEHKEH EK KE KEKE EEE E EEE EK EEE KEKE EEE KEKE EEE HEE KEKE KEK EEE KHER EES 

$! 

$! NTESTE.CTL V2,000 

$! 

$! Copyright (C) 1981 by Digital Esuipment Corporations Maynards Mass. 

$! 

$! Edit history: 

$! 

$! 2,000 24-Nov-81 DECnet/E V2,0 Release MLS 

$! 

Bl HHH HHH HEHEHE EK KE HEL EH HE HEHEHE KE HE HEHEHE HE KEE KEKE HEHEHE KEE KEKE HEHEHE KEK HEHEHE HEE EK EKESE 

$! 

$! This file is a prototype BATCH control file designed to verify that 

$! the DECnet/E software on the local node has been installed correctly. 

$! The command procedure assumes that the network has been started, 

$ ! 

$! The user should modify this file as indicated in the comments ’ 
$! to define the node’s individual configuration and the surrounding ) 
$! network configdguration. See the DECnet/E Network Installation Manual 

$! for further information on the use of this file. The Prototyre 

$! configuration below is used in all PrototyrPe installation test 

$! command files in this manual, 

$! 

BL KKK KEK HEE HHH HK HEHEHE HEHEHE KEKE EH KEKE KEE HEHEHE HEHE EH HE EHH EHH EE HEHEHE EH EERE EH EE 

$! 

$! Prototype local node assumptions: 


$ | ALPHA = your node namey ie the executor node name 

$! 1 = the executor node number 

Bl KKK HHH KEKE HEHE HEE HEE KEKE HEE EH E EHH E KKH KEE HEE EH KEE HEHE EHH EERE EKER ERE REE ’ 
$! 


$! This section contains NCP commands to perform internal loopback tests» 
$! without using any communication lines. This will verify that the 

$! network management tasks are installed where they are expected» that 

$! network tasks can be spawned by NSP» and that NSP can create logical 

$! links and transfer data over them, The "SHOW COUNTERS" commands display 
$! the number of messages transferred’ this should be compared with the 

$! "COUNT" parameter in the "LOOP" command. 

$! 


$RUN NCP 

! F ; 
! The LOOP command runs a loopback test between the local NCP and MIRROR 2.) 
! tasks. Accounting information to be Passed to the MIRROR task has been 

! omitted, If a default account has not been defined for network managment 

! on your nodes vou should insert accounting information in this command, 

\ 

SHOW EXECUTOR COUNTERS 

LOOP EXECUTOR COUNT 20 

SHOW EXECUTOR COUNTERS 

! 

! This LOOP command creates a logical link between the local NCP and NML 

' tasks» and runs a loopback test between the local NML and MIRROR tasks, 

! Modify the SET command to insert a Privileged user-id and Password» and 

! to insert the name of your local node in Place of "ALPHA". This user-id 

! and Password is Passed to the NML Programs which requires a PRIVILEGED 

! account to run loopback tests. A second set of accounting information 

! may be used in the LOOP command lines as in the example above. That 

! accounting information would be passed to the MIRROR task» and may be 

! omitted if a default account has been defined. 
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! 

SET EXECUTOR NODE ALPHA USER [i+100] PASSWORD DNETST 
SHOW EXECUTOR COUNTERS 

LOOP EXECUTOR COUNT 20 

SHOW EXECUTOR COUNTERS 

CLEAR EXECUTOR NODE 

! 


$E0D 


$! , 
$! KKH HHH LH HI HEHEHE EE EE EEE EEE EEE EEE EEE EE HEE EERE REE HEE EEE EEE 
$! 


$! This section contains NFT commands to verify that the network file 
$! access routines are installed where they are expected, and that a 

$! file can be copied within the local node. Modify the commands to 

$! insert a valid user-id and password, to insert the name of your 

$! local node in Place of "ALPHA"+ and to insure that a valid file 

$! specification appears as the source for the copy operation, 

$! 

$! These commands create a logical link between the local NFT and FAL 
$! tasks. 

$ ! 

$RUN $NFT 

COPY ALPHA::NETTST.TMP=C1 »2INTESTE.CTL 

C1+100] 

DNETST 


TYPE ALPHA: :NETTST.TMP 

DELETE ALPHA::NETTST.TMP 

$E0D 

$! 

Bl EK HEH EK HEHEHE HIKE ERE EEE HEIKKI KE EEE EEE EERE EE HEHEHE EEE EEE EE 
$! 

$EOJ 


A.3 Local Hardware Verification Control File (NTESTH.CTL) 


$JOB/CCL/NAME=NTESTH/NOLIMIT/ERROR: FATAL 


$! 

BL KEK HE KH EERE KEE EKER ER IK TK HEH HE EE EEE EEE EEE HE HEHEHE EEE EEE EE 
$! 

$! NTESTH.CTL Y2,000 

$! 

$! Copyright (C) 1981 by Digital Equipment Corporations Maynards Masse 

$! 

$! Edit history: 

$! 

$! 2,000 24-Nov-81 DECnet/E V2.0 Release MLS 

$! 

GL KEKE ERE EH EKER EH EEE EE EK KR HE TEER HR RHR EE EE EE EEE 
$! 


$! This file is a prototype BATCH control file designed to verify that the 
$! communication line hardware/firmware on a DECnet/E V2.0 node can be 

$! turned ons and will transfer data in local loopback tests. 

$! The user should modify this file as indicated in the comments 

$! to define the node’s individual configuration and the surrounding 

$! network configuration. See the DECnet/E Network Installation Manual 
$! for further information on the use of this file. The Prototype 

$! configuration below is used in all Prototype installation test 

$! command files in this manual, 

$! 

HL KKH EERE EK HEHE TR ER EK TE RE HET ET HE RHE EH EEE EEE EEE ERE ER EE 
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$! 
$! Prototype local node assumptions: 


$! ALPHA = your node name» ie the executor node name 

$! 1 = the executor node number 

$! DMR-O = Point-to-Point device 

$! DMR-1 = Point-to-Point device (answers Phone - slow line) 
$! DMP-0O = multipoint device (master) 

$! DMP-1 = multipoint device (slave) 

$! 


$! The tests below are defined for the DMR-O device only. They should 
$! be repeated as necessary for other devices on the system, 

$! Note that the second test below reauires the MANUAL installation 

$! of a hardware turnaround connectors or the MANUAL setting of a 

$! switch on a local modem, This should be done before running 

$! this command filed it will not interfere with the operation of 

$! the first tests where data is turned around within the device, 

$! 

Bl EKER HERR EHH EH HEHEHE KEK EKER EEE EERE RHEE EEE EHH EEE ERIE EE EE EEE 
$! 

$! This section performs a controller loopback test» which verifies 

$! that the circuit can be turned on» and that the device firmware 

$! can transfer data properly, The data will be turned around in 

$! the device line unit. This sequence assumes that the circuit under 
$! test is initially in the "OFF" state, 

$! 

$RUN $NCP 

! 

! These commands condition the line for the loopback test. 

! 

SET LINE DMR-0 CONTROLLER LOOPBACK 

SET LINE DMR-O VERIFICATION OFF 

SET LINE DMR-O DUPLEX FULL 

SET CIRCUIT DMR-O STATE ON 

I 


$E0D 

$! 

$! Since it may take several seconds for a circuit to complete changing 
$! state from "OFF" to "ON"» the following routine builds in a delay 
$! of 3S seconds into the batch Procedure, This value may be modified 
$! by editing this control file if it is not long enough, 

$! 

$RUN $NETSLP 

2 

$E0D 

$! 

$RUN $NCP 

1 

! This command displays the status of circuit DMR-O» to confirm that 

! it is in the "ON" state, 

1 

SHOW CIRCUIT DMR-O STATUS 

! 

! These commands define a temporary loopback nodename HTEST and 

! perform the line-level loopback test. A logical link will be created 
! between the local NCP and MIRROR tasks. The "LOOP" command assumes 

! that a default account has been defined for the MIRROR task at the 

! local node’ if not» accounting information should be supplied on the 
! "LOOP" command lines with the parameters "USER" and "PASSWORD", 

! 

SET NODE HTEST CIRCUIT DMR-0O 

SHOW NODE HTEST COUNTERS 

SHOW CIRCUIT DMR-0O COUNTERS 

! 


Loop NODE HTEST COUNT 20 
! 
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| These commands display node and circuit counters which can be compared 
1 with the "COUNT" parameter in the "LOOP" command. Also» circuit 

! counters will indicate whether any data errors were detected. 

I 


SHOW NODE HTEST COUNTERS 

SHOW CIRCUIT DMR-O COUNTERS 

I 

1 These commands restore the node and line status to the initial state 
| expected by the cable loopback test below, If the cable loopback test 
1 is removed from this control files and if the line was originally 

! half-duplex»s a command should be inserted here to return the line to 
1 half-duplex status (SET LINE DMR-O DUPLEX HALF). 

I 

SET CIRCUIT DMR-O STATE OFF 

CLEAR NODE HTEST CIRCUIT 

SET LINE DMR-0O CONTROLLER NORMAL 

' 


$EOD 


$! 
$ ! eee errr TTT TTT TTT TT TTC CTCL TCT TSS TTS PTT TTT Tek 
$! 


$#! This section performs a cable loopback test» which verifies 

$! that the circuit can be turned on» and that the device hardware 

$! can transfer data properly. The data will be turned around by 

$! a hardware turnaround connector or by a local modem; this configuration 
$! must be set up MANUALLY before this test is rune This sequence assumes 
$! that the circuit under test is initially in the "OFF" state, 

$! 

$! These commands condition the line for the loopback test, 

$! 

$RUN $NCP 

! 

SET LINE DMR-O CONTROLLER NORMAL 

SET LINE DMR-O VERIFICATION OFF 

SET LINE DMR-O DUPLEX FULL 

SET CIRCUIT DMR-O STATE ON 

! 

$E0D 

$! 

$! Since it may take several seconds for a circuit to complete changing 
$! state from "OFF" to "ON"+ the following routine builds in a delay 
$! of 5 seconds into the batch procedures This value may be modified 
$! by editing this control file if it is not long enough, 

$! 

$RUN $NETSLP 

3 

$E0D 

$ ! 

$RUN $NCP 

! 

| This command displays the status of circuit DMR-O» to confirm that 
! it is in the "ON" state, 

1 


SHOW CIRCUIT DMR-O STATUS 

! 

| These commands define a temporary loopback nodename HTEST and 
! perform the cable-level loopback test.» A logical link will be 
| created between the local NCP and MIRROR tasks. 

! 

SET NODE HTEST CIRCUIT DMR-O 

SHOW NODE HTEST COUNTERS 

SHOW CIRCUIT DMR-O COUNTERS 

t 


Loop NODE HTEST COUNT 20 
! 
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! These commands display node and circuit counters which can be compared 
! with the "COUNT" Parameter in the "LOOP" command. Also», circuit 

! counters will indicate whether any data errors were detected, 

1 


SHOW NODE HTEST COUNTERS 

SHOW CIRCUIT DMR-©O COUNTERS 

\ 

! These commands testore the node and line status. If the line was 

! originally half-duplex+s a command should be inserted to restore 

! that status also (SET LINE DMR-O DUPLEX HALF). The hardware loopback 
! connector or modem switch used to physically turn the data around must 
! be removed MANUALLY. 

! 

SET CIRCUIT DMR-0O STATE OFF 

CLEAR NODE HTEST CIRCUIT 

! 

$E0OD 

$! 

Bl KEKE KEE HHH KEE EKER HK EEE EEK HEHEHE EEE HHH HEE HEE HEHE HH KEKE EEE HEHEHE KEE EH HE 
$! 

$E0J 


A.4 Adjacent Phase III Node Verification Control File (NTESTA.CTL) 


$JOB/CCL/NAME=NTESTA/NOLIMIT/ERROR: FATAL 


$! 

Bl HERE R HEE EKER EEK HH HEE EKER EE HEHE EEE HEE EHH EKER EEE HEE KEKE EKER EEE EERE EE 
$ | 

$! NTESTA.CTL Y2,000 

$ | 


$! Copyright (C) 1981 by Digital Eauipment Corporations Maynard» Mass, 
$! 

$! Edit history: 

$! 

$! 2,000 24-Nov-81 DECnet/E V2.0 Release MLS 

$! 

Bl RHEE HHH HEHEHE HEHEHE EHH EHH EHH HEHEHE EKER H EE HEHEHE HEHEHE HEHEHE 
$! 

$! This file is a Prototype BATCH control file designed to verify that 
$! a DECnet/E V2.0 node can be connected to an adJjacent Phase III node 
$! and that data can be transferred between the two nodes, 

$! The user should modify this file as indicated by the comments 

$! to define the node’s individual configuration and the surrounding 

$! network configuration. See the DECnet/E Network Installation Manual 
$! for further information on the use of this file. The prototype 

$! configuration below is used in all Prototype installation test 

$! command files in this manual. 

$! 

Bl HER KEHKE HEE HE EHEHHEH HEHEHE HEE HEHEHE HEE HEE HEHE EHH EE HK EE KH E HEHE EHH HEE HEH KE 
$! 

$! Prototype local node assumptions: 


$! ALPHA = your node names ie the executor node name 

$ ! 1 = the executor node number 

$! DMR-O = Point-to-Point device 

$! DMR-1 = Point-to-Point device (answers Phone - slow line) 
$! DMP-90 = multipoint device (master) 

$! DMP-1 = multipoint device (slave) 

$! 
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2 


@ 


$! Prototype network node assumptions: 

$! BETA = 2 = an adjacent Phase III node via DMR-O 

$! GAMMA = 3 = an adJacent Phase II node via DMR-1i 

$! DELTA = 4 = an adJjacent Phase III tributary via DMP-0 

$! EPSILN = 5 = an addacent Phase III tributary via DMP-0O 

$! ZETA = 6 = an adJjacent Phase III master via DMP-1 

$! 

$! The test below uses circuit DMR-O to node BETA. This test should 

$! be repeated for each adjacent Phase III node on each circuit, 

$! Note that for multipoint circuits» no special Procedures are necessary» 
$! since only software-level loopback tests are used, 

$! 

Bl KKK KEKE H EE KEKE HK EEE KH EEE EEE EEE EEE EEE EEE EE EEE EEE EERE EEE HEHEHE EE EEE 
$! 

$! This section contains NCP commands to perform external loopback tests» 
$! using a communication line. This will verify that the line can be 

$! used to transfer data between the local node and the adjacent Phase III 
$! nodes and that compatible versions of network management are installed 
$! on the two nodes. The "SHOW COUNTERS" commands display the number 

$! of messages transferred} this should be compared with the "COUNT" 

$! Parameter in the "LOOP" command. 

$! 

$RUN NCP 


This command turns on the circuit to node BETA, 


SET CIRCUIT DMR-O STATE ON 


$! 

$E0D 

$! 

$! Since turning on a circuit can take several seconds: due to the 

$! node initialization process,» the following Program is run to Provide 
$! a delay of 10 seconds, The number of seconds should be modified if 
$! necessary3 note that disk I/O is performed whenever node password 
$! verification is performed, 

$! 

$RUN $NETSLP 

10 

$E0D 

$! 

$RUN NCP 


! This command displays the status of the circuit to node BETA. 
The display should confirm that the circuit is in the "ON" state 
and that the network software has initialized correctly with the 
adjacent node BETA. 


| 

I 

! 

! 

SHOW CIRCUIT DMR-O STATUS 

I 

1 This command defines a temporary loopback node name RMLOOP for the 

! circuit under test» and runs a loopback test between the local NCP 

! and MIRROR tasks. The data will be turned around by the Transport 

1 software on the remote node BETA to which the circuit is connected. 

| Modify the command to insert the name of the adjacent node in Place 

! of "BETA"+ and the circuit-id of the communications device in place 

| of "DMR-O". The "LOOP" command assumes that a default account has 

|! been defined for the MIRROR task at the local nodes if not» accounting 
| data should be supplied on the "LOOP" command lines with the "USER" 

! and "PASSWORD" Parameters, 

I 
! 
1 
I 
! 


NOTE: This loop test will fail if node BETA is a Phase III 
non-routing node. 


SET NODE RMLOOP CIRCUIT DMR-O 
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SHOW NODE RMLOOP COUNTERS 
SHOW CIRCUIT DMR-O COUNTERS 
SHOW NODE BETA COUNTERS 
SHOW EXECUTOR COUNTERS 


Loop NODE RMLOOP COUNT 20 


SHOW NODE RMLOOP COUNTERS 
SHOW CIRCUIT DMR-O COUNTERS 
SHOW NODE BETA COUNTERS 
SHOW EXECUTOR COUNTERS 


CLEAR NODE RMLOOP CIRCUIT 


! 
! 
! 
! 
! 
| 
| 
| 


This command runs a loopback test between the local NCP and the 

MIRROR task at the remote node BETA. Modify the commands to insert 

the name of the adjacent node in Place of "BETA"» and the circuit-id 

of the communications device in Place of "DMR-O", This command assumes 
that a default account has been defined for the MIRROR task on the 

node BETA: if nots accounting data should be supplied on the "LOOP" 
command lines with the "USER" and "PASSWORD" parameters, 


LOOP NODE BETA COUNT 20 


SHOW CIRCUIT DMR-O COUNTERS 
SHOW NODE BETA COUNTERS 
SHOW EXECUTOR COUNTERS 


$E0D 


$! 

Bl HK EHH EE HEE HEHEHE HEHEHE EK HEHEHE EEK KEE HEHE EE KEE HEHEHE EHH EHH HEE HHH HEE HEE HEE R EEE 
$! 

$! This section contains NFT commands to verify that the network file 
$! access routines are installed where they are expected» and that a 
$! file can be copied between nodes. Modify the commands to insert 
$! a valid user-id and password for BETA» to insert the name of your 
$! adjacent node in Place of "BETA"» and to insure that a valid file 
$! specification appears as the source for the copy operation, 

$! 

$! These commands create a logical link between the local NFT task 

$! and the FAL task on the node BETA. 

$! 

$RUN $NFT 

COPY BETA::NETTST.TMP=C1 »s2INTESTA-CTL 

C1100) 

DNETST 


TYPE BETA::NETTST.TMP 
DELETE BETA::NETTST.TMP31 


$E0D 

$! 

Bl RHEE HEHEHE HEHEHE HEHEHE KEKE HEHEHE KEKE HEHEHE EEE HEHEHE KEKE HERE E KEKE REE EEE EE HE 
$! 

$! This section turns the circuit to the adjacent node off again, 

$! 

$RUN $NCP 


! 
! 
! 
! 
! 


This command returns the local node to its Previous states so that 
links to other adJjacent nodes may be verified inderendently, 
Modify the command to insert the circuit-id of the communications 
device in Place of "DMR-O", 
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SET CIRCUIT DMR-© STATE OFF 
1 


$E0D 
$! 
$E0J 


A.5 Adjacent Phase II Node Verification Control File (NTEST2.CTL) 


$JOB/CCL/NAME=NTEST2/NOLIMIT/ERROR: FATAL 


$! 

BL RRR EHR EK ERK EE TKK EER EE EE EE EE EH EEE EE EE ER EEE EE 
$! 

$! NTEST2.CTL Y¥2,000 

$! 

$! Copyright (C) 1981 by Digital Equipment Corporations Maynard+s Mass, 

$! 

$! Edit history: 

$! 

$! 2,000 24-Nov-81 DECnet/E V2.0 Release MLS 

$! 

Bl KEKE KEE HK E EEE EEE ERE HEHEHE EH EEE EE EEE 
$! 


$! This file is a prototype BATCH command file designed to verify that 
$! a DECnet/E V2.0 node can be connected to an adjacent Phase II node 
$! and that data can be transferred between the two nodes. 

$! The user should modify this file as indicated by the comments 

$! to define the node’s individual configuration and the surrounding 

$! network configuration. See the DECnet/E Network Installation Manual 
$! for further information on the use of this file. The PrototyPre 

$! configuration below is used in all Prototype installation test 

$! command files in this manual. 

$! 

Bl HHH HERE EEE HEHEHE EEE EE EEE EEE EEE EE EEE EE EE EE HEHEHE EE EEE EEE EE EEE EEE HEHEHE EEE 
$! 

$! Prototype local node assumptions: 


$! ALPHA = your node name» ie the executor node name 

$! 1 = the executor node number 

$! DMR-O = Point-to-Point device 

$! DMR-1 = point-to-point device (answers Phone - slow line) 
$! DMP-0O = multipoint device (master) 

$ | DMP-1 = multipoint device (slave) 

$! 


$! Prototype network node assumptions: 


$! BETA = 2 = an adjacent Phase III node via DMR-O 

$! GAMMA = 3 = an adJjacent Phase II node via DMR-1 

$! DELTA = 4 = an adJacent Phase III tributary via DMP-9O 
$! EPSILN = 5 = an adJjacent Phase III tributary via DMP-0O 
$! ZETA = G = an adJjacent Phase III master via DMP-1 

$! 


$! The test below uses circuit DMR-1 to node GAMMA. This test should 

$! be repeated for each adjacent Phase II node on each relevant circuit. 
$! 

G1 KKK KKH H HEE EKER EE EEK EE HEE EEE EE RHEE EEE EEE 
$! 

$! This section contains NCP commands to perform external loopback tests» 
$! using a communication line. This will verify that the line can be 

$! used to transfer data between the local node and the adjacent Phase II 
$! nodes and that compatible versions of network management are installed 
$! on the two nodes+ The "SHOW COUNTERS" commands display the number 

$! of messages transferred’ this should be compared with the "COUNT" 

$! Parameter in the "LOOP" command, 

$! 
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$RUN NCP 

! 

! This command turns on the circuit to node GAMMA, 
| 


SET CIRCUIT DMR-1 STATE ON 

! 

$E0D 

$! 

$! Since a circuit may take several seconds to change its state from 

$! "OFF" to "ON"»> the following Program delays 10 seconds to allow the 

$! state change to complete, This time should be modified if insufficient. 
$! 

$RUN $NETSLP 


$! 

$RUN $NCP 

I 

! This command displays the status of the circuit to node GAMMA. 

! The display should confirm that the circuit is in the "ON" state 

! and that the network software has initialized correctly with the 

! adjacent node GAMMA, (Note that in the Prototype configuration 

! aboves the device DMR-1i is represented as answering a telephone 

! line in order to make the connection, If this is the case for your 
! configurations you and the remote operator at node GAMMA must 

' co-operate to form the Physical connection after each node has 

! turned its circuit "on", This may be done before starting this 

! command files since no error is generated by setting a circuit "on" 
! when it is already "on".) 

I 


SHOW CIRCUIT DMR-1 STATUS 


\ 
! This command runs a loopback test between the local NCP and the 
! Phase II NICE looper task at the remote node GAMMA, (If the node 
! GAMMA is running DECnet/E Viels the NCU task will turn the data 
! around.) Modify the commands to insert the name of the adJjacent 
! node in Place of "GAMMA"> and the circuit-id of the communications 
! device in Place of "DMR-1". The "LOOP" command assumes that a 
! default account or some other procedure exists for the Phase II 
! loopback Program on node GAMMA, If nots accounting information may 
! be supplied on the "LOOP" command with the parameters "USER" and 
! "PASSWORD". For DECnet/E Viel» this is not necessary, 

' 

SHOW CIRCUIT DMR-1 COUNTERS 

SHOW NODE GAMMA COUNTERS 

SHOW EXECUTOR COUNTERS 

! 


LOOP NODE GAMMA COUNT 20 

! 

SHOW CIRCUIT DMR-1 COUNTERS 

SHOW NODE GAMMA COUNTERS 

SHOW EXECUTOR COUNTERS 

! 

$E0D 

$! 

Gl RK HEHEHE HEHEHE EH EHH EH HEHEHE HHH KEE HEHE EHH EE HEE EEK EE HEHEHE EHH EHH KEE HEE HEHEHE 
$! 

$! This section contains NFT commands to verify that the network file 
$! access routines are installed where they are expected» and that a 
$! file can be copied between nodes, Modify the commands to insert 
$! a valid user-id and password for GAMMA» to insert the name of your 
$! adjacent node in place of "GAMMA",s and to insure that a valid file 
$! specification appears as the source for the cory operation, 

$! 


A-14 DECnet/E Network Installation Guide 


$! These commands create a logical link between the local NFT task 
$! and the FAL task on the node GAMMA. 

$! 

$RUN $NFT 

COPY GAMMA::NETTST.TMP=C1+2INTEST2.CTL 

C1+100] 

DNETST 


TYPE GAMMA::NETTST.TMP 

DELETE GAMMA::NETTST.TMP$1 

$E0D 

$! 

Bl HK EH EEK EEK KK IK EK EE EE RE EK HEE EEE EEE HE KE EHR EE EEE EEE EEE EEE 
$! 

$! This section turns the circuit to the adjacent node off again, 
$! 

$RUN $NCP 

! 

| This command returns the local node to its previous states so that 
! links to other adjacent nodes may be verified independently. 

| Modify the command to insert the circuit-id of the communications 
! device in Place of "DMR-1i",. 

1 


SET CIRCUIT DMR-1 STATE OFF 
! 


$E0D 
$! 
$EOJ 


A.6 DTS/DTR Control File (DTSDTR.CTL) 


$JOB/CCL/NAME=DTSDTR/NOLIMIT/ERROR: FATAL 


$! 

Bl HHH HEE HEHEHE HEE EEE EEE HEHEHE EE EEE EEE EEE HEHE HEHEHE EEE EEE EEE HEHEHE EEE EEE EEE EEE 
$! 

$! DTSDTR.CTL Y2,000 

$! 


$! Copyright (C) 1981 by Digital Eauipment Corporations Maynard» Mass. 

$! 

$! Edit history: 

$! 

$! 2,000 24-Nov-81 DECnet/E V2.0 Release MLS 

$! 

GL KKH KKH HEHE HEE EK HH EEE EE EE EK EEE EE HEHE EEE EE EE EEE EEE ERE EEE EEK 
$! 

$! This file is a prototype BATCH command file designed to verify that 

$! a DECnet/E V2.0 node can be connected to an adjacent Phase II node 

$! and that data can be transferred between the two nodes, 

$! The user should modify this file as indicated by the comments 

$! to define the node’s individual configuration and the surrounding 

$! network configuration. See the DECnet/E Network Installation Manual 
$! for further information on the use of this file. The PrototyPre 

$! configuration below is used in all prototype installation test 

$! command files in this manual, 

$! 

Bl RHR KKH H HEE KEKE KEKE RHE EEE EEE EEE EK HE REE EE EEE EEE EE HEE EEE 
$! 
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$1 KERR EERE EEE EEE EEE HEHE EEE HEHEHE EEE EEK HEE RHEE HEHE EEE EER HE KEE HEE EEE EEE RHR REE 
$! 


$! This section turns the circuit to the adjacent node off again, 
$! 
$RUN NCP 


! This command returns the local node to its previous state; so that 
! links to other adJjacent nodes may be verified independently, 

! Modify the command to insert the circuit-id of the communications 
! device in Place of "DMR-1", 

1 


SET CIRCUIT DMR-1 STATE OFF 
! 

$E0D 

$ | 

$EOJ 


A.7 Network Startup Command File (DECNET.CMD) 


DETACH 

LOGIN KB: [172] 

FORCE KB: RUN $UTILTY 

FORCE KB: SEND KBO: "Starting up Decnet/E V2.0" 
FORCE KB: 

FORCE KB: CCL TLK= 

FORCE KB: CCL NCP= 

FORCE KB: CCL NFT= 

FORCE KB: CCL NET= 


FORCE KB: CCL TLK- =C1s21]TLK.* sPRIY 30000 
FORCE KB: CCL NCP- =C€1s23NCP.TSK sPRIY 30000 
FORCE KB: CCL NFT- =Cis2INFT.TSK jPRIV O 
FORCE KB: CCL NET-WORK=C1i,+,2]NET.TSK SPRIVY 30000 
FORCE KB: EXIT 

FORCE KB: 


FORCE KB: RUN $TTYSET 
FORCE KB: WIDTH 80 
FORCE KB: EXIT 


FORCE KB: 
FORCE KB: 
FORCE KB: 
FORCE KB: 


designed to be used with the RSTS system startup Procedure} see the 
RSTS/E SYSGEN Manual for a description of this startup Procedure. 
See the DECnet/E Network Installation Manual for further information 
on the use of this file. Note that this file assumes that the 


FORCE KB: 
FORCE KB: RUN $NCP 
FORCE KB: ! 
FORCE KBr! HHH KKK HH HHH EHH HEHEHE HEE EHH HEHEHE KEKE EEE HHH HEHEHE KE EEE EHH HERR E EE EHH KEKE HEHKREHEEH 
FORCE KB: ! 
FORCE KB: ! DECNET.CMD Y2.,000 
FORCE KB: ! 
FORCE KB: ! Copyright (C) 1981 by Digital Equipment Corporations Maynard» Mass, 
FORCE KB: ! 
FORCE KB: ! Edit history: 
FORCE KB: ! 
FORCE KB: ! 2,000 24-Nov-81 DECnet/E V2.0 Release MLS 
FORCE KB: ! 
FORCE KBr |! HH HH R EHH H HH EEK HH EER HEHEHE HEE KEKE EKER HK H EKER KEE HEE EEK EER EE 
FORCE KB: ! 
FORCE KB: ! This file is a prototype NCP command file designed to start up 
FORCE KB: ! a DECnet/E ¥2.0 network, It does not start any circuits» since it 
FORCE KB: ! is designed for use in an installation checkout Procedure; wherein 
FORCE KB: ! circuits will be turned on and checked one at a time. The file is 
I 
1 
! 
! 
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Q 





FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
FORCE 
ATTACH 


! 
! 
! 
! 
! 
! 
! 
! 
I 
I 
! 
I 
! 
! 
! 
l 
| 
! 
| 
S 
! 
! 
| 
! 
! 
! 
! 
I 
I 
! 
Ss 
! 
! 
| 
! 
! 
! 


Startup Procedure is being run from the Ci+2] accounts and that the 
network tasks reside in the [€1+2] account. Edit this file» if 
necessary, to change the accounts to those specific to your system. 


KEKE KKEKEKEE KEKE KEKE EEK EEE REE EER EKER KKREEEEE EERE KEEKEEEKKEKREKREKKREEEEEEE 


Prototype local node assumptions: 
ALPHA = your node name+y ie the executor node name 
1 = the executor node number 


KEKE E EEE EEE EEK EEK EEE EEE KEKE REE HERE REE KE KEKE KE EEE KEKE KE ERERREKER 


This command loads the volatile Parameter file from the Permanent 
Parameter file. If no volatile Parameter file exists» one will be 
created, The volatile Parameter file will be installed as a RSTS/E 
system files and the event logger will be started if the NCP command 
"DEFINE ALL LOGGING STATE ON" was issued for the Permanent Parameter 
file. 


ET SYSTEM 


Any temporary changes to your network configuration or operating 
Parameters can be made now with NCP "SET" commands’ they will not 
affect the Permanent Parameter file, 


KEE KEKE KEE EEE ERE EEE REE EEE KEE EEE HEE EKER HEE EEK EKER EK EKEHEHEE KH KRE HEHEHE KHEKEREE 


This command starts network orPerations ies turns the network on, 
Internal data structures for Transport and NSP are initialized, 


ET EXECUTOR STATE ON 


KEKE KERR EEE KEKE EEE KRE HEHEHE EKER HEHEHE KEEKEKKE EEE HEHEHE KKEREHEEEEE 


This command starts the circuits which are in normal use, Edit 
this file to change the names of the circuits to those used on 
your system, 


SET CIRCUIT DMR-O STATE ON 
SET CIRCUIT DMR-1 STATE ON 
SET CIRCUIT DMP-0.0 STATE ON 


KEKE EEK HEHEHE KREEKEREE KEKE EEE EEEKKKKRKEHRHEEKREKKHRKEEKKKKEEEE 


The following command starts NPKDYR such that it will run as a 
detached Job and accept uP to eight incoming network terminal 
connections, If NPKDVYR is not started this way» it will be 
sPawned anew for each incoming connect into a separate job slot 
(assuming it has been defined as an obJect with an NCP DEFINE 
OBJECT command). 


RUN #NPKDYVR,.TSK 
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Appendix B 
Object Type Codes 


Code 


000 
001 
002 
003 
004 
005 
006 
007 
008 
009 
010 
011 
012 
013 
014 
015 
016 
017 
018 
019 
020 
021 
022 
023 
024 
025 
026 
027 
028 
029-062 
063 
064-127 
128-255 


Type of Process 


General Task, User Process 

File Access (FAL/DAP Version 1) 
Unit Record Services (URD) 
Application Terminal Services (ATS) 
Command Terminal Services (CTS) 
RSX-11M Task Control, Version 1 
Operator Services Interface 

Node Resource Manager 

IBM 3270-BSC Gateway 

IBM 2780-BSC Gateway 

IBM 3790-SDLC Gateway 

TPS Application 

RT-11 DIBOL Application 

TOPS—20 Terminal Handler 
TOPS—20 Remote Spooler 

RSX-11M Task Control, Version 2 
TLK Utility (LSN on DECnet/E) 

File Access (FAL/DAP Version 4 and later) 
RSX-11S Remote Task Loader 
Network Management Listener (NICE Process) 
RSTS/E Media Transfer Program (NETCPY) 
Reserved for DECnet use 

Mail Listener 

Host Terminal Handler (NPKDVR) 
Concentrator Terminal Handler 
Loopback Mirror 

Event Receiver 

VAX/VMS Personal Message Utility 
File Transfer Spooler (FTS) 
Reserved for DECnet use 

DECnet test tool (DTR) 

Reserved for DECnet use 

Reserved for customer extensions 


Appendix C 


Hardware Loopback Testing 


The term loopback refers to the testing mechanisms in which data passes 
from its source, through a number of network components, and back to the 
source. If the data returns uncorrupted, that portion of the communications 
circuit is assumed to be functioning properly. 


There are five levels of loopback testing possible with DECnet/E V2.0. Each 
level is characterized by the number of system components through which 
the data passes and the point in the circuit at which the data is turned 
around and returned to its source. These five levels are illustrated in Figure 
C-1 and are listed below: 


1. 


Local logical link loopback. Local loopback occurs when a local pro- 
gram establishes a logical link with itself or with another program at 
the local node. Data is turned around at the local Transport layer. 


Controller loopback. Controller loopback occurs when the commu- 
nications controller (the DMC11, DMR11, DMV11 or DMP11) is 
placed in a special maintenance mode. Data is turned around within 
the controller itself, without involving the cable, modem (if any), or 
physical communications line. 


Hardware loopback. Hardware loopback occurs when the data is 
turned around by a physical loopback device installed or enabled in 
the communications circuit, somewhere between the local controller 
and the remote system. 


. Remote node loopback. Remote node loopback occurs when the data 


is turned around by the remote Transport layer before reaching a net- 
work or user program on the remote node. (This type of loopback is 
only available on Phase III routing nodes.) 


Remote logical link loopback. Remote logical link loopback occurs 
when a program on the local node establishes a logical link with a 
remote program designed to return data to its source. The data is 
turned around at either the remote network application layer, net- 
work management layer, or user layer. 


NOTE 


Some DECnet implementations include another level of 
loopback — referred to as “line” loopback. This type of loop- 
back uses a special maintenance protocol (Maintenance 
Operation Protocol, or MOP) operating through the com- 
munications device itself. DECnet/E does not support this 
type of line loopback, since it does not support any of the 
MOP functions. 


Proceeding through these levels of testing, the loopback point moves pro- 
gressively further away from the source of data. Thus, each level tests for 
accurate data transmission one step further out from the local system, mak- 
ing it possible to isolate any problem to a particular hardware or software 
component of the communications circuit. 


This appendix is concerned with loopback tests that test the commu- 
nications hardware from the local controller to the remote end of the phys- 
ical communications line. Section C.1 describes the NCP command 
sequences necessary to initiate the tests. The actual hardware con- 
figurations required to test a communications circuit in point-to-point mode 
and in multipoint mode are discussed in Sections C.2 and C.3, respectively. 
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Figure C-1: Levels of Loopback Testing 
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C.1 Loopback Command Sequences 


Controller-level loopback tests use a special maintenance feature of the 
communications controller to loop back data within the device itself. Other 
hardware components are not involved and there is no need to install addi- 
tional loopback connectors or to disconnect cables or modems. The device 
must, however, operate in full-duplex mode. (See Figure C—2.) 


To enable the controller maintenance function and run the loopback test, 
type the following NCP command sequence: 


SET CIRCUIT circuit-id STATE OFF 

SET LINE line-id DUPLEX FULL 

SET LINE line-id CONTROLLER LOOPBACK 
SET NODE node-id CIRCUIT circuit-id 

SET CIRCUIT circuit-id STATE ON 

LOOP NODE node-id <options> 


The circuit-id identifies the communications line being tested, the line-id 
identifies the controller, and node-id is the temporary loopback node name 
being assigned to the loopback circuit. See the DECnet/E System Manager's 
Guide for the syntax of the options that can be specified with the LOOP 
NODE command. 


COMMUNICATION 
CIRCUIT 


EIACABLETO... f VO 
7 
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DEVICE MUST OPERATE DATA IS LOOPED BY CONTROLLER 
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POINT-TO-POINT MODE CABLE, MODEM, COMMUNICATION 
CIRCUIT, OR REMOTE SYSTEM. 
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Figure C-2: Controller-Level Loopbacks 


Hardware-level loopback tests operate by installing or enabling a loopback 
device at some point in the communications circuit. Once the hardware is 
configured properly (as described in Sections C.2 and C.3), the line must be 
conditioned (that is, established with network management as a loopback 
circuit) before the actual test can be run. 
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To condition the line and run the loopback test, type the following NSP com- 
mand sequence: 


SET CIRCUIT circuit-id STATE OFF 

SET LINE line-id DUPLEX FULL 

SET LINE line-id CONTROLLER NORMAL 
SET NODE node-id CIRCUIT circuit-id 

SET CIRCUIT circuit-id STATE ON 

LOOP NODE node-id <options> 


Once again, the circuit-id identifies the communications line, the line-id 
identifies the controller, and node-id is the temporary loopback node name 
assigned to the loopback circuit. See the DECnet/E System Manager’s Guide 
for the syntax of the options that can be specified with the LOOP NODE 
command. 


Data directed to a program on the loop node passes through the controller 
and out to the loopback point. At the loopback point it is turned around, 
returned through the controller, and delivered to the target program for 
analysis. The target program actually runs on the local node. Setting a 
pseudo-node name to the circuit under test tells the Transport module to 
route all traffic addressed to that node name onto the specific circuit and to 
accept the looped data as input to the local node. 


C.2 Point-to-Point Hardware-Level Loopback 


This section discusses the hardware arrangements necessary to do hard- 
ware-level loopback tests on DMC11/DMR11 controllers and on 
DMV11/DMP11 controllers set up for point-to-point communication. In 
terms of loopback testing, there is only one main difference between the var- 
ious controllers. Typically, the DMR11, DMV11, and DMP11 have a con- 
nector/distribution panel between the controller and the actual 
communications line; the DMC11 does not. Thus, circuits operating with a 
DMC11 contain one less component to be tested. 


NOTE 


Since the DMR11, DMV11, and DMP11 all have similar 
hardware configurations, for the rest of this section the 
term DMR11 will be used to refer to all three of these con- 
troller types. 


The hardware arrangements necessary to do hardware-level loopback tests 
depend on the type of connecting cables used with the controller. In general, 
there are two types of cable — ribbon (EIA) cable and coaxial (pigtail) cable. 
The following subsections discuss the hardware arrangements required for 
testing circuits involving each type. 
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C.2.1 Ribbon Cable 


Ribbon cable is generally used when the physical path to a remote system 
involves either switched (dial-up) or leased (private) telephone lines. Typi- 
cally, such a communications circuit covers an extended distance and 
includes modems at both the local and remote ends of the line. 


Diagrams A through E in Figure C-3 show the hardware configuration for 
the two types of controllers when ribbon cable is used. In both cases, one end 
of the cable connects to the controller’s line unit board. With the DMC11, 
the other end of the cable terminates in a standard EIA connector that plugs 
directly into the local modem (see Diagram A). With the DMR11, on the 
other hand, the cable terminates at a connector panel, with a second cable 
connecting the panel and the modem (see Diagram B). The actual panel used 
depends on the type of cable. (Table C—1 lists some common cable interfaces 
and their appropriate panels.) Diagram C shows the most frequently 
installed panel, for use with RS-232-C and RS-423-A interface cables, and 
Diagram D shows the panel used with RS-422-A interface cables. Diagram 
E shows the special case DMRI1 cabling used with V.35 interface modems 


that eliminates the connector panel completely. 
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Figure C-3A: DMC11 Controller with Ribbon Cable 
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Figure C-3B: DMR11 Controller with Ribbon Cable 
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Figure C-3C: BC55C-XX (RS-232-C/RS-423-A Interface) Panel Cable 
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Figure C-3D: BC55B-XX (RS-422-A Interface) Panel Cable 
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Figure C-3E: BC05Z-XX (V.35 Interface) Modem Cable 


Loopback Connectors 


Testing the hardware components from the controller to the local modem 
requires the installation of a loopback test connector at some point in the 
communications path. The type of connector used depends on the type of 
cable. Table C—1 lists the connector types for the various cable interfaces. 


To test the communications path up to the connector/distribution panel (if 
any), the loopback connector is installed in the appropriate jack in the panel 
(as listed in Table C—1), the line is “conditioned” with the NCP command 
sequence given in Section C.1, and the loopback test is run. 


To test the remainder of the path up to the local modem, the cable is 
unplugged from the modem and the loopback connector is installed in the 
connector at the end of the cable. The line is conditioned and the test is run, 
as before. 
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Table C—1: Cable Panels and Test Connectors 


Cable Cable Loopback Panel 
Interface Panel Connector Test Jack 
RS-232-C BC55C H325 J2 
RS-422-A BC55B H3251 J2 
RS-423-A BC55C H3251 Jl 

V.35 BC05Z H3250 - 


Local Modem Loopback 


To test the communications path out to, and including, the local modem, a 
special maintenance feature of the modem is used. A common option is an 
analog loopback feature that directs the modem’s transmitter output to its 
receiver input. This feature is usually activated by a switch, such as the 
analog loopback (AL) button available on Bell 208A and 208B modems. 


NOTE 


The discussions of modem loopback features, here and in 
the following subsection, are based on Bell 200 series 
modems manufactured by Western Electric. Almost all 
modems have loopback and self-test options or features. 
Since hardware implementations differ among the various 
manufacturers, the precise details for doing loopback tests 
can differ from what is described here. Consult the oper- 
ation manual for your modems regarding loopback features 
before using the procedures given here. 


The modem converts digital data from the controller to an analog signal 
that would normally be transmitted over the communications line. With the 
analog loopback feature enabled, however, the transmitter output (the 
analog signal) is fed back into the modem receiver. (See Figure C—4.) The 
receiver digitizes the analog signal and returns the digital data to the 
controller. 


LOCAL MODEM — 
ANALOG LOOP ENABLE 
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FULL DUPLEX (FDX) MODE DIGITAL DATA ON EIA CABLE 


Figure C—4: Local Modem Loopback 
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The controller hardware requires Data Set Ready to be on (asserted) before 
it will transmit data, but many modems clear this signal when analog loop 
is enabled. Bell 208A, 208B, and 209 modems offer a strapping option that 
determines whether the Data Set Ready signal is asserted or negated when 
the modem is in the analog loop test mode. Bell refers to this as the “CC 
Indication of Analog Loop (ON/OFF)” option. 


If your modem clears Data Set Ready, but does not offer a strapping option 
such as described above, the local modem loopback test cannot be run with- 
out the use of a “breakout box” between the controller and the modem. A 
schematic of a typical breakout box, and the connections required to perform 
an analog loop test with a modem that clears Data Set Ready, are shown in 
Appendix D, Figure C-1. 


To configure a communications circuit for local modem loopback, remove 
any loopback connectors installed for previous tests and reconnect the cable 
to the modem. Disconnect (hang up) the telephone line to the remote system 
and enable analog loopback on the local modem. Use the command sequence 
given in Section C.1 to condition the line as a loopback circuit and run the 
test. The controller must operate in full-duplex mode, even though the 
modem can be connected to a 2-wire (half-duplex) telephone line. Since the 
telephone circuit is not used, the type of line does not affect the operation of 
the test. 


Remote Modem Loopback 


The communications path can be tested up to and including the remote 
modem by using another common maintenance feature of the modem. This 
option, known as digital loopback, directs the modem’s receiver output to its 
transmitter input. The feature is generally activated by a switch, such as 
the digital loopback (DL) button available on the Bell 208 modems. 


In this case, the local modem operates normally in that it converts digital 
data from the controller to an analog signal and transmits the signal over 
the communications line. The remote modem’s receiver converts the analog 
signal to digital form and loops the digital data back to its transmitter. The 
remote modem’s transmitter converts the digital data to an analog signal 
and transmits the analog signal back over the telephone circuit. The local 
modem digitizes the data once again and returns it to the controller. (See 
Figure C-5.) 
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Figure C-5: Remote Modem Loopback 


To configure a communications circuit for remote modem loopback, ask the 
remote operator to disable the line interface connected to the remote modem 
and to enable the digital loopback feature. (Some modems have a remote 
digital loop option that allows a local operator to switch the remote modem 
into digital loopback without the intervention of an operator at the remote 
site.) Next, condition the communications line as a loopback circuit using 
the NCP command sequence given in Section C.1. Establish the telephone 
connection to the remote modem and run the loopback test. 


Unlike the other tests described so far, the type of communications line does 
matter for this type of loopback test. The entire circuit (including both 
modems and the communications lines themselves) must be capable of full- 
duplex operation. Switched (dial-up) telephone lines are 2-wire circuits. 
Although there are several modems that operate full-duplex over 2-wire cir- 
cuits, a 2-wire line usually implies half-duplex operations. In some circum- 
stances, dual-dial arrangements can be used to create a 4-wire full-duplex 
channel from two switched lines. Leased (private) lines can be either 2- or 4- 
wire circuits. Basically, if your installation is not set up for full-duplex com- 
munication to the remote system, you cannot perform remote modem 
loopback. 


C.2.2 Coaxial Cable 


Coaxial (pigtail) cable is generally used when the physical path to a remote 
system covers only a short distance. Telephone circuitry is not involved and 
no modem is required. 


Figure—6 shows the normal hardware configuration for the two types of con- 
trollers when coaxial cable is used. In the case of the DMC11, two coaxial 
cables connect to the line unit board and extend through the opening at the 
back of the mounting box. The cables are approximately one foot long and 
terminate in 4-pin female connectors (see A in, Figure C-6). 


DECnet/E Network Installation Guide 


e) 


Oo 


With the DMR11, on the other hand, a cable connects the line unit board toa 
connector/distribution panel (see B, in Figure C—6). The connector panel has 
four 4-pin connectors — two male and two female (see C, in Figure C—6). Ina 
point-to-point configuration, only two of these connectors are used and have 
cables attached. The other two are fitted with 75 ohm terminators. 
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Figure C-6B: DMR11 Controller with Coaxial Cable 
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Figure C-6C: Coaxial Connector Panel 
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To test the communications path from the DMR11 to the connector panel, 
the duplex switch in the center of the panel is set to half-duplex (HDX). This 
causes the outgoing data to be turned around at the panel and returned to 
the controller. In this case, the data is also transmitted out over the cable. 
Thus, to prevent the remote system from mistakenly responding to the data 
sent and corrupting the test results, either the outgoing cables should be 
physically disconnected from the panel, or the circuit should be turned off 
(at the remote system) using the SET CIRCUIT STATE OFF command, or 
the NCP command that is apropriate at the remote node. When the neces- 
sary hardware adjustments have been made, the line is conditioned and the 
test is run, using the NCP command sequence given in Section C.1. 


To test the cables to the remote system — either from the DMC11 line unit 
board or from the DMR11 connector panel — the cables are disconnected (at 
the remote end) and a loopback device is installed, connecting the ends of 
the two cables. The device used depends on the connector type on the end of 
the cables. If the cables terminate in female connectors, a small feed- 
through connector (12-12528) can be used (see Figure C—7). If the cables ter- 
minate in male connectors, a short (one foot) cable, fitted with two female 
connectors, should be used. 
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Figure C—7: Coaxial Cable Loopback Connector 


NOTE 


If the line to the remote system consists of more than one 
physical piece of cable, both types of loopback devices and 
several separate loopback tests may be necessary, along the 
length of the line, to completely test the line. 


If the remote controller is a DMR11-type device (as shown in Diagrams A 
and B of Figure C-6), the remote connector panel itself can be used as the 
loopback device. To do this, the duplex switch in the center of the remote 
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panel is set to half-duplex (HDX). Incoming data is then turned around by 
the panel and sent back over the line to the local controller. The data is also 

© transmitted through the remote connector panel to the remote controller. 
Thus, once again, to prevent the remote system from responding to the data 
and corrupting the test results, the circuit should be turned off (at the 
remote system) using the SET CIRCUIT STATE OFF command, or the NCP 
command that is appropriate. 


When testing the line with a DMR11-type controller, no matter which hard- 
ware arrangement is used, be certain to reset the duplex switch on the local 
connector panel to the full-duplex position (FDX). 


Once the necessary hardware adjustments have been made, the line is con- 
ditioned and the loopback test is run, using the NCP command sequence 
given in Section C.1. 


NOTE 


Cc Note that the DMR11 circuit shown in Diagram B of Figure 
C-6 is configured for full-duplex operation. Hardware-level 

loopback tests beyond the connector/distribution panel can 

only run with a full-duplex circuit. If you have a DMR11- 

type controller configured for half-duplex, it must be 

altered to full-duplex operation before running these tests. 


‘@) C.3 Loopback Tests in a Multipoint Environment 


In general, hardware loopback tests — either at the device level or the line 
level — are not really possible in a multipoint environment. To do installa- 
tion testing of multipoint hardware or to isolate a problem in a running mul- 
tipoint chair, the hardware must be reduced to a point-to-point 
configuration. 


Installation testing has already been discussed in the previous section. Each 

Cc hardware component is simply tested in point-to-point mode, and when all 
components function satisfactorily, they can be cabled together in a multi- 
point configuration. Isolating a problem in a running multipoint environ- 
ment, however, does have some side effects that should be mentioned. 


If a problem is suspected in a particular controller, the system to which that 
device is attached must be isolated from the rest of the multipoint chain. 
The operating protocol of the controller is then changed to point-to-point. 
This is done with the following NCP command sequence: 


SET CIRCUIT circuit-id STATE OFF 
SET LINE line-id PROTOCOL DDCMP POINT 


(Note that the protocol of a controller cannot be changed while the circuit is 
operational. Further, to change the protocol of the control station, all cir- 
cuits from the controller must be turned off.) 
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After that, controller-level loopback tests can be run, using the command 
sequence given in Section C.1. No cables need to be disconnected, and 
assuming the affected station is not the control station, running the loop- 
back test in this fashion has no effect on the remainder of the multipoint 
chain. If the affected station is the control station, however, this procedure 
will destroy the entire multipoint environment unless another station can 
be designated as the control station. 


If a problem is suspected in the portion of the circuit from a particular con- 
troller to its distribution panel, the station must be physically isolated from 
the chain. The cables must be disconnected from the front of the distribution 
panel and connected together, bypassing the station altogether. (Be certain 
to connect “Transmit In” to “Transmit Out” and “Receive In” to “Receive 
Out.”) 


After the station has been isolated in this fashion, and the controller’s oper- 
ating protocol has been changed to point-to-point (with the command 
sequence shown above), hardware-level loopback tests can be run between 
the controller and the panel. Once again, assuming that the affected station 
is not the control station, this procedure has no effect on the remainder of 
the multipoint chain. 


If a problem is suspected in the hardware between two adjacent stations, 
however, both stations must be isolated from the chain and a point-to-point 
circuit must be established between them. This procedure will usually sig- 
nificantly disrupt the multipoint environment. 


Consider the 5-station multipoint chain shown in Figure—8. To run hard- 
ware- or node-level loopback tests between tributaries C and D, those two 
stations must be isolated from the rest of the chain. Their operating pro- 
tocols must be changed to point-to-point and the hardware must be con- 
figured so that there is a direct (point-to-point) circuit between them. To 
prevent interference from the control station (B), the cables between sta- 
tions B and C must be disconnected (see Diagram B, in Figure C-8). Under 
these circumstances, the control station is no longer able to communicate 
with tributary E (although it is still able to communicate with tributary A). 
In fact, no station can communicate with tributary E. (Note that there is no 
need to disconnect the cables between stations D and E, since tributary E 
will not respond to any transmission other than a poll from the control 
station.) 


Thus, before running controller- or hardware-level loopback tests in this 
fashion, consideration must be given to the effect on the total multipoint 
environment. 
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Appendix D 
EIA/CCITT Interface Notes 


D.1 EIA/CCITT Interface Notes 


In the early days of data communications in the United States, the associ- 
ated operating companies of American Telephone and Telegraph were, for 
all practical purposes, the only providers of data communications services. 
Therefore, the modems developed by the engineers at Bell Laboratories and 
manufactured by Western Electric were the standards of the industry. As 
time went on, computer and terminal equipment manufacturers needed to 
know the electrical characteristics of Bell modem interfaces. Similarly, as 
independent companies began to offer competing modems, they needed to 
know the electrical characteristics of the interfaces offered by the computer 
and terminal manufacturers. 


To avoid chaos, the Electrical Industry Association (EIA), in cooperation 
with the Bell System, the independent modem manufacturers, and the com- 
puter manufacturers, developed a standard for the interface between Data 
Terminal Equipment (DTE) — computers and terminals — and Data Commu- 
nication Equipment (DCE) — modems — employing Serial Binary Inter- 
change. This standard is called RS-232, or more specifically RS-232-C, 
reflecting the latest (C) revision. Newer standards, RS-422 and RS-423, 
have been developed that will eventually replace the RS-232-C standard, 
but RS-232-C is still the standard to which modem interfaces are designed. 


In countries other than the United States, data communication services are 
usually provided by government Post, Telegraph, and Telephone (PTT) 
authorities. To permit the economic manufacture of modems, terminals, and 
computers, and to facilitate data communications between various coun- 
tries, the PTTs of the United Nations countries, in cooperation with the 
Comite Consultatif International Telephonique et Telegraphique (CCITT), 
also developed standards for data communication interfaces. Due to varying 
requirements, nationalism, and other factors that preclude firm standards, 
CCITT working committees develop recommendations that are adopted and 
published by the CCITT as a whole. These recommendations are numbered 
and published in books. The current volume relating to data communication 
is Volume VIII which contains recommendations prefixed with the letters V 
and X. CCITT recommendation V.24 is similar to the EIA RS-232-C stand- 
ard in the USA. 


Some of the information in this appendix was reproduced from “Technical Aspects of Data Commu- 
nications” by John E. McNamara, published by the Educational Services Department, Digital Equip- 
ment Corporation. 


Returning to the EIA standard, it is important to note exactly what the 
standard contains. 


@ The electrical signal characteristics (voltage, currents, impedances, and 
so forth). 


@ Mechanical characteristics of the interface (connector and pin assign- 
ments information). 


e A functional description of the interface circuits. 


e A list of standard subsets of specific interchange circuits for particular 
applications. 


A brief description of the EIA/CCITT interface is provided in Table D-1. 


Table D-1: EIA/CCITT Interface Summary 


Circuit Mnemonic 
PIN Direction EIA/CCITT Name Description 
1 AA/101 FG Protective (Frame) Ground. This con- 


ductor is an electrical equipment 
frame ground. It can be further con- 
nected to external grounds as 
required by applicable regulations. 


2 — DCE BA/101 TD Transmitted Data. This conductor 
carries the serial digital data trans- 
mitted from the DTE (computer or 
terminal) to the DCE (modem). The 
DCE then converts the digital data to 
a form that can be sent over the com- 
munication facilities to the remote 
system. 


3 DTE — BB/104 RD Received Data. Signals on this con-' 
ductor are generated by the receiving 
DCE (modem) in response to data 
received from the remote system. 
This is the digital data sent from the 
remote system to the _ local 
equipment. 


4 — DCE CA/105 RTS Request to Send. The ON condition of 
this lead causes the modem to assume 
the data transmit mode. 


5 DTE — CB/106 CTS Clear to Send. Signals on this circuit 
indicate whether or not the modem is 
ready to transmit data. The ON con- 
dition of this lead, coupled with ON 
conditions on circuits CA, CC, and 
CD (when implemented) indicate that 
data presented on circuit BA (trans- 
mitted data) will be transmitted to 
the remote system. 


(continued on next page) 
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Table D-1 (Cont.): EIA/CCITT Interface Summary 


PIN Direction Circuit Mnemonic 
EIA/CCITT Name 


6 DTE— CC/107 DSRorMR_ Data Set Ready or Modem Ready. 
This circuit indicates the status of the 
local modem. An ON condition 
indicates that the local modem is 
ready to process data (modem is con- 
nected to the communication circuit; 
call is established; all handshaking 
has been completed; modem is not in 
test, talk, or dial mode). 


7 AB/102 SG Signal Ground. This conductor estab- 
lishes the common reference poten- 
tial for all interchange circuits except 
circuit AA (protective ground). 


8 DTE — CF/109 DCDorCD Data Carried Detect (Received Line 
Signal Detector). The ON condition of 
this lead indicates that the DCE 
(modem) is receiving a signal (from 
the remote system) that meets the 
suitability criteria established by the 
modem manufacturer (that is, a sig- 
nal the modem can understand). 


9 DTE— Positive DC Test Voltage. Used for 
testing only. 
10 DTE— Negative DC Test Voltage. Used for 
testing only. 
11 Not assigned by RS-232-C. 
DTE — BELL 208A QM Equalizer Mode. 
12 DTE — SCF/122 (S)DCD Secondary Data Carrier Detect. (Sec- 


ondary Received Line Signal Detec- 
tor). This line performs the same 
function as circuit CF (Data Carrier 
Detect) except that it indicates proper 
reception of a signal on the secondary 
channel rather than the primary 
channel. 


13 DTE— SCB/121 (S)CTS Secondary Clear to Send. This signal 
performs the same function as circuit 
CB (Clear to Send) except that it 
indicates availability of the second- 
ary channel rather than the primary 
channel. 


14 —DCE SBA/118 (S)TD Secondary Transmitted Data. This 
signal performs the same function as 
circuit BA (Transmitted Data) except 
that it carries data from the DTE to 
the modem for transmission on the 
secondary channel rather than the 
primary channel. 


(continued on next page) 
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Table D-1 (Cont.): EIA/CCITT Interface Summary 


PIN Direction Circuit Mnemonic 
EIA/CCITT Name 


— DCE BELL 208A NS New Sync. 


15 DTE — DB/114 TC Transmitter Clock (Transmitter Sig- 
nal Element Timing — DCE Source). 
This circuit is used to provide signal 
element timing information to the 
DTE. The DTE provides a data signal 
on circuit BA (Transmitted Data) in 
which the transitions between signal 
elements (bits) nominally occur at the 
time of the OFF to ON transition of 
this lead. Used by the DTE (computer 
or terminal) to determine when it 
should present the next data bit on 
the transmitted data lead. 


16 DTE — SBB/119 (S)RD Secondary Reveived Data. This line 
performs the same function as circuit 
BB (Received Data) except that it car- 
ries data received by the modem on 
the secondary channel. 


DTE — BELL208A DCT Divided Clock, Transmitter. 


17 DTE — DD/115 RC Receiver Clock (Receiver Signal Ele- 
ment Timing — DCE Source). This 
lead provides the DTE with received 
signal timing information. The ON to 
OFF transition of this signal nomi- 
nally occurs at the center of each sig- 
nal element (bit) on circuit BB 
(Received Data). Used by the DTE to 
determine when it should read data 
from the Received Data Line. 


18 Not assigned by RS-232-C 
DTE BELL 208A DCR Divided Clock, Receiver. 
19 — DCE SCA/120 (S)RTS Secondary Request to Send. This sig- 


nal performs the same function as cir- 
cuit CA (Request to Send) except that 
it requests use of the secondary chan- 
nel rather than the primary channel. 


20 — DCE CD/108.2 DTR Data Terminal Ready. Signals on this 
lead are used to control switching of 
the DCE to the communication chan- 
nel. The ON condition prepares the 
DCE for connection and maintains a 
connection established by external 
means such as manual call origina- 
tion, manual answering, or automatic 
call origination. 


(continued on next page) 
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Table D-1 (Cont.): EIA/CCITT Interface Summary 


PIN Direction Circuit Mnemonic 
EIA/CCITT Name 


21 DTE — CG/110 SQ Signal Quality Detect. This circuit is 
used to indicate to the DTE whether 
or not there is a high probability of 
errors in the received data. The ON 
condition is maintained when there is 
no reason to believe that an error has 
occurred. An OFF condition indicates 
that there is a high probability of 
error. 


22 DTE— CE/125 RI Ring Indicator. The ON condition of 
this circuit indicates that a ringing 
signal is being received on the com- 
munication channel. In switched net- 
work applications the DTE (com- 
puter) would be expected to answer 
the call by asserting circuit CD (Data 
Terminal Ready). 


23 — DCE CH/11 Data Rate Selector (DCE Source). 
This signal is used to select between 
two data signalling rates in the case 
of a dual rate synchronous modem. 

-The ON condition selects the higher 
data rate. 


DTE — Cl/112 Data Rate Selector (DCE Source). 
This signal is used to select one of two 
data signalling rates in the case of 
dual rate synchronous modems. The 
ON condition selects the higher data 
rate. 


24 — DCE DA/113 (TC) External Transmitter Clock (Trans- 
mitter Signal Element Timing — DTE 
Source). This circuit is used to pro- 
vide the transmitting signal con- 
verter (modem transmitter) with sig- 
nal element timing information. The 
ON to OFF transition of this lead 
nominally corresponds to the center 
of each element (bit) on circuit BA 
(Transmitted Data). 


25 Not assigned by RS-232-C. 
—DCE BELL 208A Busy. Used for testing. 
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D.2 Breakout Box Application Notes 
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Several manufacturers of data communication equipment market a piece of 
test equipment called a “breakout box” (or similar name). The purpose of the 
box is to allow patching and monitoring of the various leads of the 
EIA/CCITT interface. A schematic of a typical breakout box is shown in Fig- 
ure D-1. 


As shown in Figure D-1, the typical breakout box consists of two 25-pin EIA 
connectors, switches to break any of the signal lines, test/patch points to 
allow special interconnections, and, in many cases, a set of indicator lights 
for monitoring signals. The connector on the left in the drawing is a female 
EIA connector that is connected to a terminal or computer (DMC11 or other 
line interface hardware) with an EIA cable (see Figure D-2). The connector 
on the right is a male connector that plugs into a modem. 


With all switches closed as shown in Figure D-1, the breakout box has no 
effect on the interface signals. If indicator lights are provided, they can be 
used to monitor common control signals (RTS, CTS, DSR, DCD, DTR, SQ, 
and RD) or Transmitted Data (TD) and Received Data (RD) leads. 


Figure D-3 demonstrates use of a breakout box for a specific application. 
Recall that a DMx controller will not operate unless the modem asserts Data 
Set Ready (Circuit CC — Pin 6). However, many modems negate DSR when 
analog loopback is enabled. To get around this problem, a breakout box can 
be set up as shown in Figure D-3. Note that Data Terminal Ready (Circuit 
CD - Pin 20), that is asserted by the DMx whenever it is enabled, is con- 
nected to Data Set Ready. Furthermore, the DSR lead from the modem is 
broken by an open switch. Hence, DSR, as seen by the controller, is asserted 
whenever DTR is asserted (that is, whenever the DMx is ON). Since many 
modems do not process control signals when operating in a loopback mode, 
several other patches may also be necessary. In Figure D-3, Request to Send 
(Circuit CA — Pin 4), that is asserted by the controller when it wants to 
transmit, is fed back to the device as Clear to Send (Circuit CB — Pin 5) and 
Data Carrier Detect (Circuit CF — Pin 8). The CTS and DCD leads from the 
modem must also be broken by open switches. This arrangement will allow 
an analog loopback test to be run with a modem that either negates Data Set 
Ready or does not process control signal when analog loopback is enabled. 
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Figure D-2: Connecting a Breakout Box 
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Breakout Box Connections for Analog Loop Test 
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Appendix E 
DTS/DTR Utility Program 


The Data Test Sender (DTS) and the Data Test Receiver (DTR) are the DEC- 
net/E transmitter and receiver test programs. The object libraries and com- 
mand files to build DTS and DTR are included on your DECnet/E 
distribution kit and are used during the system generation procedure. 
Appendix A (Section A.6) lists the DTS/DTR command files, also supplied on 
the distribution kit, that should be used to test connections to adjacent 
Phase II nodes. 


E.1 Types of Tests 


There are four basic tests provided by DTS and DTR. 
e Connect Tests 

e Data Tests 

e@ Disconnect Tests 

e Interrupt Tests 


Each test is divided into a set of subtests. The tests and subtests are 
described in the following sections. 


E.1.1 Connect Tests 


Connect tests are designed to test the ability of the network software to proc- 
ess connect, connect accept, and connect reject requests — with and without 
optional user data. Connect tests that the user can perform are as follows: 


@ Connect reject without user data 

e@ Connect accept without user data 

e Connect reject with 16 bytes of standard user data 

e Connect accept with 16 bytes of standard user data 

© Connect reject with received user data used as reject user data 


e Connect accept with received user data used as accept user data 


E-1 


E-2 


E.1.2 Data Tests 


Data tests provide a full range of test capabilities from the very simple data 
sink operation through data integrity checking. Data tests that the user can 
perform are as follows: 


e@ Sink Test. DTR ignores all data received. No sequence of content valida- 
tion is performed. 


e@ Sequence Test. Data messages transmitted by DTS or DTR include a 4- 
byte sequence number. If a message is received out of sequence, DTR 
aborts the logical link and the test. 


e Pattern Test. Data messages transmitted to DTR have both a sequence 
number and a standard data pattern. If either the sequence number or the 
received data does not match the expected data, DTR aborts the logical 
link and the test. 


@ Echo Test. Data messages received by DTR are transmitted back to DTS. 
No sequence or data validity checking is done by either DTR or DTS. 


E.1.3 Disconnect Tests 


Disconnect tests are designed to determine whether DTS can detect the dif- 
ference between disconnect and abort sequences generated by DTR as well 
as receive the proper optional user data. Disconnect tests that can be per- 
formed by the user are as follows: 


e Disconnect without user data 

e Abort without user data 

e@ Disconnect with 16 bytes of standard user data 

e@ Abort with 16 bytes of standard user data 

e Disconnect with received connect user data as disconnect user data 


e Abort with received connect user data as abort user data 


E.1.4 Interrupt Tests 


Interrupt tests provide a full range of test capabilities from very simple data 
sink operations through data integrity checking. Interrupt tests that the 
user can perform are as follows: 


e@ Sink Test. DTR ignores all interrupt data received. No sequence or con- 
tent validation is performed. 


@ Sequence Test. Interrupt messages transmitted by DTS to DTR include a 
4-byte sequence number. If a message is received out of sequence, DTR 
aborts the logical link and the test. 
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e Pattern Test. Interrupt messages transmitted to DTR have both sequence 
number and a standard data pattern. If either the sequence number or the 
received data does not match the expected data, DTR aborts the logical 
link and the test. 


e Echo Test. Interrupt messages received by DTR are transmitted back to 
DTS. No sequence or data validity checking is done by either DTR or 
DTS. 


E.2 Operational Characteristics 


DTR functions as a slave to DTS. DTS initiates each test by issuing a con- 
nect request to DTR. Parameter information pertinent to the type of test 
requested is passed by DTS to DTR in the optional data of the connect 
request. DTS has a user interface that enables the user to specify the test to 
be performed. Sufficient parameters are available to allow for a variety of 
tests, including test duration, buffer size, and buffering level. 


The version of DTR supplied on the DECnet/E distribution kit supports a 
maximum of three logical links, thus allowing three concurrent tests. DTS 
can handle only a single test and logical link, but the user can invoke mul- 
tiple copies of DTS. 


The DTS command syntax allows two types of buffer level. parameters: 
DEPTH and FCOUNT. DEPTH is used by DTS only and FCOUNT is used 
by DTR only. The DEPTH parameter specifies the transmit buffering level 
for DTS. This is the number of transmission requests that DTS attempts to 
keep outstanding to the network. In an echo test, the DEPTH parameter 
also specifies the receive buffer level for DTS. The FCOUNT parameter 
specifies the receive buffering level for DTR. 


Both DTS and DTR have 512 bytes of buffer space, built into each task, at 
the end of each task image. To increase the buffer space of either task, the 
user must edit the BASIC program and recompile. DTS requires at least 
(DEPTH*SIZE) bytes of buffer space for a data test, and 
((DEPTH + 1)*SIZE) bytes for an echo test. DTS requires (FCOUNT*SIZE) 
bytes of buffer space for each data test. 


E.3 DTS Command Syntax 


The syntax of DTS commands is very “free form” in nature. Commands are 
composed of keywords and parameters, separated by whitespace (i.e., tabs or 
spaces) and/or special characters. Colons (“:”) and equal signs (“=”) are 
interchangeable and are used to associate parameters with keywords. 
Parameters take two forms: numeric or text. 


A command must be completed in a single line. Keywords can begin with or 
without slashes (as the user sees fit), and the name of the test to be run must 
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be specified before any options. Thus, the following are all valid (and synon- 
ymous) commands: 


DATA ECHO /SIZE=256 /MINUTES=2 /FLOW=SEGMENT/FCOUNT=1 
/DATA/TYPE=ECHO/FLOW=SEGMENT/FCOUNT=1/SIZE=256/MINUTES=2 


DATA TYP:ECHO FLO:SEG FC:i SIZE:256 MIN:2 
DATA/SI2=256 ECHO SEG/FC=1 MIN=2 


Formats for DTS commands are described below. The following conventions 
apply to the presentation and use of these commands: 


Parentheses( ) Indicate an optional parameter. 
Braces { } Indicate a choice of parameters or keywords. 


UPPERCASE Indicates the actual keyword or parameter text that 
appears in the call. 


lowercase italic Indicates a parameter that is replaced with an actual 
value when invoked. 


E.3.1 Specifying the DTS Node 


(NODE = nodename) \ (UID=uid) (/PASSWORD=pwd) (/ACCOUNT=act) (/PRINT) 
(nodename::) 


nodename Specifies the name of the node where DTR resides. Default is the local node. 


uic Specifies the user ID, project-programmer number (PPN), or user identi- 
fication code (UIC) for access to the remote node. 


pwd Specifies the password for access to the remote node. 
act Specifies the billing account for access to the remote node. 
NOTE 


The /PRINT option is used by DECnet/E DTS to either display or sup- 
press message output to the local console device. Messages include both 
test results and error messages. 


E.3.2 Connect Test 


CONNECT type Pelee ca } 
/RETURN = data 


type Type of connect test: 


ACCEPT Connect accept test 
REJECT Connect reject test 


data _ Type of user data returned: 


STANDARD Standard user data 
RECEIVED Return connect user data 
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E.3.3 Disconnect Test 


DISCONNECT type { /NORETURN \ 
/RETURN = data 


type Type of disconnect test: 


SYNCHRONOUS Synchronous disconnect test 
ABORT Abort test 


data Type of user data returned: 


STANDARD Standard user data 
RECEIVED Return connect user data 


E.3.4 Data Test 


DATA type {SECONDS = aa /SIZE=mm_ /DEPTH=bb { /NOFLOW | /FCOUNT=ff 
/MINUTES = nn \ FLOW =fit 


type Type of data test: 


SINK Sink test 
SEQUENCE Sequence test 
PATTERN Pattern test 
ECHO Echo test 

nn Test duration. 


mm Data message length, in bytes. Must be greater than 0 for for a sink or echo test, 
greater than 4 for a sequence test, and greater than 5 for a pattern test. The max- 
imum value is 1024 bytes. 


bb DTS transmit buffering level, in the range of 1 to 16. 
fit Flow control type: 


SEGMENT Segment flow control 
MESSAGE Message flow control 


ff Number of segments/messages requested if /FLOW was selected. 


E.3.5 Interrupt Test 


INTERRUPT type §/SECONDS=nn { /SIZE=mm 
/MINUTES = nn 


type Type of interrupt test: 


SINK Sink Test 
SEQUENCE _ Sequence test 
PATTERN Pattern test 
ECHO Echo test 


nn Test duration 


mm Data message length, in bytes. Must be greater than 0 for a sink or echo test, greater 
than 4 for a sequence test, and greater than 5 for a pattern test. The maximum value 
is 16 bytes. 
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ADDRESS parameter, 2-5 

Adjacent node, 
Phase II verification, 4-1, 4-6 
Phase III verification, 4-1 to 4-5 
testing, 4-1 

Alias, 3-9 

Analog loopback, C-8 


BATCH control files, 
output, 1-2, 3-7, 4-5 
Breakout box, C-9, D-6 
Buffer pool, 
extended, 
See XBUF, 1-5 
small, 3-9 
BUFFER SIZE parameter, 2-6, 3-3 
BUILD, 1-1, 1-5 to 1-6 


Cc 


Cables, 
coaxial (pigtail), C-4, C-10 to C-13 
connecting, C-4 
ribbon (EIA), C-5 to C-10 
CCITT, D-1 
Circuit, 2-7 
conditioning for testing, 3-8, C-3 to C-4 
consistency checking of parameters, 3-8, 4-3 
counters, 3-9 to 3-10, 4-3, 4-5 
error counters, 3-10, 4-3 
initializing, 3-8, 4-3 
maximum, 2-2 to 2-3, 2-7, 3-3 
state, 3-8, 4-3 


Comite Consultatif Internactional Telephonique et 


Telegraphique, 

See CCITT : 
Communications hardware, 1-4, 3-1 
Conditioning circuit, C-3 to C-4 
Configuration control file, 

constructing, 2-1 to 2-2 

correcting, 3-2 

running, 2-6 to 2-7 
Connecting cables, 

See Cables, 

Connector panel, C-4, C-8, C-11 
Consistency checking, 
of circuit parameters, 3-8, 4-3 
of network parameters, 3-2 


INDEX 


Control files, 

running under BATCH, 1-2 
Controller-level loopback, C-3 to C-4 

multipoint, C-14 
Conversion utility, 

See NCUCVT 
Cost, 

maximum, 2-4, 3-3 
Counters, 

circuit, 3-9 to 3-10, 4-3 

executor, 3-5, 4-3 

node, 3-9, 4-3 


Data Communication Equipment, 

See DCE 
Data Terminal Equipment, 

See DTE 
Data Test Receiver, 

See DTS/DTR 
Data Test Sender, 

See DTS/DTR 
DCE, D-1 
DECNET.CMD, 

See DECnet/E startup command file 
DECnet/E library, 3-6 

building, 1-5 to 1-6 

job area, 1-5 
DECnet/E startup command file, 2-7 to 2-8, 3-1 
DECnet/E V1.1, 

upgrading from, 2-1 to 2-2 
Default network account, 2-2, 3-4, 3-9, 4-2 
Digital loopback, C-9 
Distribution medium, 1-1, 1-3, 1-5 

BATCH control files, 1-2, A-1 t 

contents, 1-1 to 1-2 
Distribution panel, 

See Connector panel 
DMC11/DMR11, 1-4 
DMP11/DMVI11, 1-4 
DMx controllers, 

controlling access to, 1-5 

difference between, C-4 

specifying configuration, 1-4 
DTE, D-1 
DTS/DTR, 4-6, E-1 to E-5 
DTSDTS.CTL, 

See Adjacent node, Phase II verification 
Duplex, C-3, C-9 to C-10, C-13 

full, 3-8 

half, 3-10 


Index 


EIA, D-1 
Electrical Industry Association, 
See EIA 
End node, 2-3, 4-2 
Error counters, 
circuit counters, 3-10, 4-3 
executor counters, 3-5 to 3-6, 4-3, 4-5 
node counters, 3-10, 4-3 
Event logger, 3-1 
as a message receiver, 3-3 
console logging, 2-2, 2-8 
default logging file, 2-2 
file logging, 2-8 
logging filters, 2-8 
logging sinks, 2-8 
message output, 1-2 
remote event logging, 4-1 
starting, 3-2 
task image file, 3-2 
EVTLOG, 
See Event logger 
Executor, 
ADDRESS, 2-5 
counters, 3-5, 4-3 
error counters, 3-5 to 3-6, 4-3, 4-5 
Extended buffer pool, 
See XBUF 


File Access Listener, 
See NFT/FAL 
File transfer software, 
See NFT/FAL 
Filters, 
See Event logger 
Full-duplex, 3-8 


Half-duplex, 3-10 
Hardware, 
specifying configuration, 1-4 
HARDWARE LIST option (INIT.SYS), 3-1 
Hardware-level loopback, 3-7 
analog loopback, C-8 
conditioning circuit, C-3 to C-4 
connectors, 
See Loopback connectors 
difference between controllers, C-4 
digital loopback, C-9 
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duplex, C-3, C-9 to C-10, C-12 to C-13 
local modem loopback, C-8 to C-9 
multipoint, C-13 to C-14 
point-to-point, C-4 to C-13 
remote modem loopback, C-9 to C-10 
use of breakout box, C-9 

Hop, 
maximum, 2-3 to 2-4, 3-3 


INIT.BAS (RSTS/E startup control program), 2-8, 


3-1 


INIT.SYS (RSTS/E system initialization program), 


1-5 
HARDWARE LIST option, 3-1 
SET PRIV option, 1-5 
specifying SWAP MAX, 1-5 
specifying XBUF usage, 1-5 


L 


LIST CIRCUIT CHARACTERISTICS command 
(NCP), 3-10 


LIST EXECUTOR CHARACTERISTICS command 


(NCP), 3-6 
LIST NODE CHARACTERISTICS command 
(NCP), 3-10 
LIST SWAPFILES command (UTILITY), 3-2 
Local hardware verification, 3-7 
Local software verification, 3-4 
Logical links, 
active links, 3-6 
connect failures, 3-4 to 3-5, 4-4 
incoming connect request, 3-6 
LOOP EXECUTOR command (NCP), 3-4 
LOOP NODE command (NCP), 3-4 
Loopback connectors, 3-8, 4-1, 4-3, C-7 to C-8, 
C-12 
Loopback node name, 3-8, 4-3 
Loopback tests, C-1 to C-15 
adjacent Phase II verification, 4-6 
adjacent Phase III verification, 4-2 to 4-5 
bad response, 3-4, 3-10, 4-5 
command sequences, C-3 to C-4 
conditioning circuit, 3-8, C-3 to C-4 
controller-level, 3-7, C-3 to C-4, C-14 
hardware adjustments, 3-7 
hardware-level, 
See Hardware-level loopback 
levels, C-1 
local hardware verification, 3-7 to 3-10 
local software verification, 3-4 
multipoint, C-13 to C-14 
time to run, 3-6 
use of temporary node name, 3-8, 4-3 





@ 
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Maintenance Operation Protocol, 

See MOP 
MAXIMUM ADDRESS parameter, 2-5, 3-3 
MAXIMUM CIRCUITS parameter, 2-2 to 2-3, 2-7, 
3-3 
MAXIMUM COST parameter, 2-4, 3-3 
MAXIMUM HOPS parameter, 2-3 to 2-4, 3-3 
MAXIMUM VISITS parameter, 2-4 to 2-5, 3-3 
MIRROR, 2-2, 3-4, 4-2, 4-4 
Modem, C-8 to C-9 
MOP, C-1 
Multipoint, 1-4, 4-1 

loopback tests, C-13 to C-14 


NCP, 1-5, 3-2, 3-4, 4-2, 4-4 
NCPDEF.CTL, 

See Configuration control file 
NCU.SYS, 2-1 
NCUCVT, 2-1, 2-6 
NETOFF, 2-8 
NETPRM.SYS, 

See Permanent parameter file 
Network Control Program, 

See NCP 
Network diameter, 2-4 
Network File Transfer, 

See NFT/FAL 
Network Management Listener, 

See NML 
Network parameters, 

consistency checking, 3-2 

constraints, 3-3 

examining, 2-6 to 2-7 

inadequately defined, 3-5 to 3-6, 3-10, 4-3, 4-5 
NFT/FAL, 1-5 to 1-6, 2-2, 3-6, 4-5 
NML, 1-5, 2-2 
Node, 

adjacent, 

See Adjacent node 

alias, 3-9 

counters, 3-9, 4-3, 4-5 

duplicate node name, 3-9 

error counters, 3-10, 4-3 

loopback node name, 3-8, 4-3 

maximum address, 2-5 to 2-6, 3-3 

specifying address, 2-5 
NTEST2.CTL, 

See Adjacent node, Phase II verification 
NTESTA.CTL, 

See Adjacent node, Phase III verification 
NTESTE.CTL, 

See Local software verification 
NTESTH.CTL, 

See Local hardware verification 


Object type codes, B-1 
P 


Patching DECnet/E, 1-3, 1-6 
Path, 2-4 
Path length, 2-4 
Peripheral Interchange Program, 
See PIP 
Permanent parameter file, 2-1, 2-6 to 2-7, 3-2 
Phase II, 
adjacent node verification, 4-6 
utilities available, 4-6 to 4-7 
Phase III, 
adjacent node verification, 4-2 to 4-5 
PIP, 2-2, 3-2, 3-6 
Point-to-point, 3-8 


REACT, 2-2 
Record Management System, 
See RMS 
Remote event logging, 4-1 
RMS, 1-5 
Routing, 4-2 
cost, 2-4 
end node, 2-3 
hop, 2-3 to 2-4 
network diameter, 2-4 
path, 2-4 
path length, 2-4 
Routing node, 2-3 
Routing table, 2-3, 2-5, 3-3 
RS-232, D-1 
RSTS/E startup command file, 2-8 
RSTS/E system initialization program, 
See INIT.SYS 
RSTS/E system library, 1-6, 3-6 
RSTS/E startup control program, 
See INIT.BAS 
RSX Run-Time System, 1-5 


S 


Segment size, 2-6, 3-3 

SET ALL LOGGING STATE ON command 
(NCP), 3-3 

SET CIRCUIT OWNER EXECUTOR command 
(NCP), 3-8 

SET EXECUTOR command (NCP), 2-2 

SET EXECUTOR DEFAULT ACCOUNT 
command (NCP), 3-4, 3-9 


Index 


SET EXECUTOR STATE ON command (NCP), 
3-2 
SET PRIV option (INIT.SYS), 1-5 
SET SYSTEM command (NCP), 3-1 
SHOW ACTIVE LINKS command (NCP), 3-6 
SHOW CIRCUIT CHARACTERISTICS command 
(NCP), 3-8 
SHOW EXECUTOR COUNTERS command 
(NCP), 3-6 
SHOW KNOWN NODES command (NCP), 3-9 
SHOW KNOWN OBJECTS command (NCP), 3-6 
SHOW LINE CHARACTERISTICS command 
(NCP), 3-8 
Sinks, 
See Event logger 
Small buffer pool, 3-9 
Spawn Job system function, 3-3 
START.CTL, 
See RSTS/E startup command file 
SWAP MAX, 1-5 
SYSGEN, 1-1 
network configuration questions, 1-3 to 1-4 
SYSTAT, 2-8, 3-3, 3-6 
System generation, 
See SYSGEN 


T 


TELL prefix (NCP), 3-4 
Transport, 4-2 
Tributaries, 1-4, 2-3, 4-1 
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Upgrading from Version 1.1, 2-1 to 2-2 
User accounts, 
$ designator, 1-6, 3-6 
network default, 2-2, 3-4, 3-9, 4-2 
system library, 1-6, 3-6 
UTILITY program, 3-2 


Vv 


Visits, 
maximum, 2-4 to 2-5, 3-3 
Volatile parameter file, 3-1 
as a swap file, 3-2 
consistency checking, 3-2 


xX 


XBUF, 1-5, 2-3 
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READER’S COMMENTS 
NOTE: This form is for document comments only. DIGITAL will use comments submitted on this form at the 


company’s discretion. If you require a written reply and are eligible to receive one under Software 
Performance Report (SPR) service, submit your comments on an SPR form. 


Did you find this manual understandable, usable, and well-organized? Please make suggestions for improvement. 














Did you find errors in this manual? If so, specify the error and the page number. 











Please indicate the type of user/reader that you most nearly represent. 














QO — Assembly language programmer 
OO Higher-level language programmer 
O —— Occasional programmer (experienced) 
O User with little programming experience 
O Student programmer 
O —— Other (please specify) 
Name Date 
Organization 
Street 
City_._ State LT Zip Code 
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